Change in the way e10s and multi are enabled on Nightly

[Blake Kaplan]

Hello everybody,

I'm in the process of landing a change in bug 1406212 [1] that changes the
way that we handle enabling or disabling of e10s and e10s-multi. This
change will ride the trains, so Firefox 58 will be the first version with
the simplified logic.

To recap the current situation: we have 4 prefs that control these
features: browser.tabs.remote.autostart, browser.tabs.remote.autostart.2,
dom.ipc.processCount, and dom.ipc.processCount.web. On Nightly,
browser.tabs.remote.autostart.2 defaults to true and dom.ipc.processCount
defaults to 4. On Beta and Release, they default to false and 1
respectively. We then update these preferences via the e10srollout addon.
This has been the cause of much confusion and several bugs.

As of today (assuming the patch sticks), these features will be controlled
by the prefs browser.tabs.remote.autostart and dom.ipc.processCount. They
default to true and 4, respectively and behave as one would expect.

One more thing to point out: with the removal of e10srollout, I also
removed the code that would disable e10s if we detected a
non-multiprocessComptaible extension. We are entirely relying on the addon
manager to refuse to install such extensions.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1406212
--
Blake

[Justin Dolske]

On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan <mrb...@mozilla.com> wrote:

>
> One more thing to point out: with the removal of e10srollout, I also
> removed the code that would disable e10s if we detected a
> non-multiprocessComptaible extension. We are entirely relying on the addon
> manager to refuse to install such extensions.
>
>

If someone on a pre-release channel enables legacy addons, will that still
refuse to load non-E10S compatible addons? (I hope so?)

Justin

[Andrew Swan]

Legacy extensions can only be enabled on nightly and unbranded builds (not
on beta). On Nightly, a non-MPC extension won't load unless you also flip
the preference extensions.allow-non-mpc-extensions. If both those prefs
are flipped on Nightly, we will load the extension with shims enabled but
will not disable e10s.

Why don't we rip this all out you ask? We're still using shims in
automation, see bug 1351512. If anybody reading this has some spare cycles
(ha) and wants to do a good deed, you should be able to find remaining uses
by running tests with extensions.interposition.enabled set to false and
tracing resulting failures...

-Andrew