reconsider MOZ_ALLOW_LEGACY_EXTENSIONS behavior
Categories
(WebExtensions :: General, enhancement, P5)
Tracking
(firefox74 fixed)
Tracking | Status | |
---|---|---|
firefox74 | --- | fixed |
People
(Reporter: mixedpuppy, Assigned: mixedpuppy)
References
Details
(Whiteboard: devrel-note)
Attachments
(1 file)
At a minimum, we could rename that to ALLOW_EXTENSION_EXPERIMENTS or something, but we have both isPrivileged and experimentsAllowed looking at appconstant and/or a pref. It's not clear why that is being done when looking at the code.
Assignee | ||
Comment 2•5 years ago
|
||
Legacy extensions are no longer loaded, so we can drop the build config for it. We
still need flags for handling experimental APIs since what we require differs between builds
and distributions.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Geoff, do we need any of this for Thunderbird or are we good with the way we use WebExtensions now?
Comment 4•5 years ago
|
||
I think this is fine but I need to look more closely. Leaving the NI? until I can do that.
This is a problem though:
get addonExperimentsAllowed() {
return this.NIGHTLY_BUILD || this.MOZ_DEV_EDITION;
},
Assignee | ||
Comment 5•5 years ago
|
||
Geoff, I'll land this patch in the next day or two. In addition to the above, any build that has MOZ_REQUIRE_SIGNING set to false will be able to set the preference. Based on what is in mozilla-central, this patch essentially does not change what builds can set the expiremental preference.
Comment 6•5 years ago
|
||
Right. That's fine. I'd done nothing here because of a lack of Bugzilla action … but of course everything's happened on Phabricator and I forgot to subscribe to that. :-/
Comment 7•5 years ago
|
||
This hasn't gone so well though: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=ba22d3581ecc4563acabf714809b71711c9cd194&group_state=expanded
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_upgrade.js | xpcshell return code: 0
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_upgrade.js | test_1 - [test_1 : 111] Extension 1 is active - false == true
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_onPropertyChanged_appDisabled.js | xpcshell return code: 0
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_onPropertyChanged_appDisabled.js | run_test - [run_test : 29] false == true
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_strictcompatibility.js | xpcshell return code: 0
xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_strictcompatibility.js | test_1 - [test_1 : 113] Expected value of addon.appDisabled - true deepEqual false
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
Geoff, the latest patch addresses those failures. I'll have to deal with them in more detail in the followup bug 1608552.
Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
We should announce this far and wide.
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
bugherder |
Comment 13•5 years ago
|
||
There's one reference of MOZ_ALLOW_LEGACY_EXTENSIONS left in toolkit/mozapps/extensions/test/xpcshell/test_temporary.js
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
Hello,
If this ticket requires manual testing please provide the steps to reproduce/test. Otherwise, the "qe verify -" flag should be set.
Thank you
Assignee | ||
Updated•5 years ago
|
Comment 16•5 years ago
|
||
Comment 17•5 years ago
|
||
Part of this fix adds a line to firefox.js setting pref("extensions.experiments.enabled", false);
Is that intentionally part of this bug? Experiments are not discussed explicitly as part of it anywhere that I see, and it has had the effect of disabling experiments where they were previously enabled.
Updated•2 years ago
|
Description
•