I’ve tried to find documentation about this, but without success - is it intentional that Experiments can’t be signed? I know they can’t be published on AMO, but I didn’t find anywhere stating a policy that they couldn’t be signed unlisted.
The AMO signing tool is stating that “You cannot submit this type of add-on”, but I’m not sure if that’s intentional policy, or just not working properly.
I don’t think extensions are currently meant for redistribution as third parties, and thus there is no signing. I think there were plans to eventually allow that, but I don’t think it’s currently actively pursued.
Thanks - so if I understand right, it’s currently official policy that Experiments may not be signed? Is that documented anywhere?
Further, the policy may eventually change in the future, but not likely to happen any time soon.
I’d say the fact that the documentation states https://webextensions-experiments.readthedocs.io/en/latest/uplifting.html#what-if-it-doesn-t-land-in-firefox for the case where an experiment is not considered as a full API with Firefox is about as close to documentation for that you’ll get.
It only says “It can still be used by Nightly and Developer Edition.”, which would be the case because it requires the extensions.legacy.enabled pref to be set true, and only Nightly and Developer support that pref.
To me, there’s nothing there that implies a policy that experiments can’t be signed. It seems a bit of a shame to have to disable signature checking just to install an experiment, really.
Experiments don’t need the legacy pref, at least not the current iteration that is bundled as a normal web extension.
If Experiments are not supposed to need the legacy pref then there’s a bug with Extension.jsm.
Following the logic of experimentsAllowed through to isPrivileged, an experiment is allowed if it is a system or built-in addon, or if it’s been loaded temporarily, or if the extensions.legacy.enabled pref is enabled.
When I tried it in Nightly, the experiment addon would appear loaded in the list without the pref enabled, but would not actually be loaded, and trying to temporarily load any addon which depended on it would fail (during lazy instantiation)
I can confirm that the legacy pref is needed. I have an addon with an combined experiment to get a toolbar and i was not aware that the pref is still needed. My legacy pref was still activated from the past as the experiment was still a separate legacy addon, but now with combined experiment i would not expect this.