Closed Bug 1088309 Opened 5 years ago Closed 5 years ago
Disable addons not specifically compatible with e10s when enabling e10s
We have some addons that cause terrible performance, let's disable them when e10s is enabled.
Note that the multiprocessCompatible manifest flag also disables Firefox's addon compatibility shims. If we disable addons that do not declare themselves to be multiprocessCompatible, then we will be disabling some addons that already work correctly using the shims. All the work to develop the shims will have been for naught. Disabling these addons for our initial e10s rollout on Nightly is prudent, but we should consider removing this check when e10s rides the trains.
Component: General → Extension Compatibility
OS: Mac OS X → All
Hardware: x86 → All
There's very little context presented in this bug, and alarm bells are ringing in my head after seeing it and discussing with felipe. We shouldn't be blindly disabling massive groups of add-ons - that's just a recipe for disaster, and undoes all the good work we put into making add-ons compatible by default. At the very least, I expect to see data on the number/usage of impacted add-ons, a look into the strategies for how to determine what add-ons should be affected, and the AMO team weighing in (because they're the only ones with adequate context).
We had a separate email conversation about this (sorry) and I said as much. I don't think it's useful to disable add-ons wholesale, since our objective is precisely to get add-ons tested and debugged on Nightly, and there shouldn't be such a high expectation of add-on stability on Nightly as on other channels. If there are add-ons causing serious performance problems, I can mark their current versions as incompatible with Nightly.
Per the e10s meeting this morning we're not going to do this.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.