1088309 - Disable addons not specifically compatible with e10s when enabling e10s

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

We have some addons that cause terrible performance, let's disable them when e10s is enabled.

Comment 1

[Chris Peterson [:cpeterson]]

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.

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

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).

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 4

[Dave Townsend [:mossop]]

Per the e10s meeting this morning we're not going to do this.