Make a plan on how to deploy e10s in Tor Browser
Our current goal is to make Tor Browser based on ESR 52 ready for content sandboxing (e10s). While the work is done in different bugs we need to create a plan on how we want to deploy it. For that we need to investigate first how Mozilla is shipping it in Firefox 52 ESR. E.g. there is a system extension e10srollout and there is an e10s allow list and probably some other means that are regulating which users are getting which experience (i.e. having e10s and non-e10s) activated (Things like https://bugzilla.mozilla.org/show_bug.cgi?id=1329695 make me quite cautious).
Once we know how this is going to work (mike conley had an idea in: https://groups.google.com/forum/#!topic/mozilla.dev.platform/TWE4VEbJOmM not sure if that's the final word or where we can find out more information) we can think about how we want to have it work in Tor Browser to have a stable yet more secure browsing experience.
Activity
My feeling is that we should keep things as simple as possible: once we make sure that the add-ons we bundle are working correctly with multiple processes, we should enable e10s by default for all Tor Browser users. Most of what Mozilla is doing is to accommodate add-ons that do not support e10s, but since we do not really support third party add-ons it seems reasonable for Tor Browser to use a simpler approach than Firefox. Also, if we believe https://wiki.mozilla.org/Electrolysis#Schedule then e10s mode will be on by default for all Firefox 52 users (I am not sure if something different will be done for the ESR though).
If we adopt this approach, it means that someone who wants to use an add-on that is not compatible with e10s will need to turn off e10s mode via about:config. Mozilla has used several different prefs to control e10s (which has led to some confusion), so we will need to ensure that we provide good instructions on how to disable it.
There is also a chance that we will discover that e10s mode in ESR52 is too slow or not stable enough to turn on by default.
Replying to mcs:
My feeling is that we should keep things as simple as possible: once we make sure that the add-ons we bundle are working correctly with multiple processes, we should enable e10s by default for all Tor Browser users. Most of what Mozilla is doing is to accommodate add-ons that do not support e10s, but since we do not really support third party add-ons it seems reasonable for Tor Browser to use a simpler approach than Firefox. Also, if we believe https://wiki.mozilla.org/Electrolysis#Schedule then e10s mode will be on by default for all Firefox 52 users (I am not sure if something different will be done for the ESR though).
If we adopt this approach, it means that someone who wants to use an add-on that is not compatible with e10s will need to turn off e10s mode via about:config. Mozilla has used several different prefs to control e10s (which has led to some confusion), so we will need to ensure that we provide good instructions on how to disable it.
I am debating whether we actually should follow Mozilla here because there is the inherent risk that users will just complain Tor Browser is not working while Firefox is which seems a thing we can actually avoid. Additionally, we would be avoiding bugs that Mozilla is not hitting because they disabled e10s if known extensions are installed that are incompatible with it.
This entails a lot of complexity. I think we should try to understand how complex that system actually is (Are there any updates to the list of incompatible extensions shipped? If so, how? What about add-ons where the e10s compatibility is not known? etc.) and make then a final decision whether it is worth taking the shortcut you propose or not.
Replying to gk:
Our current goal is to make Tor Browser based on ESR 52 ready for content sandboxing (e10s). Content Sandboxing is another task: https://wiki.mozilla.org/Firefox/AddOns/Status/current#Sandboxing To make Tor Browser based on ESR 52 ready for content sandboxing, ESR 52 should be ready for e10s. While the work is done in different bugs we need to create a plan on how we want to deploy it. For that we need to investigate first how Mozilla is shipping it in Firefox 52 ESR. e10s qualification criteria for ESR52: https://bugzilla.mozilla.org/show_bug.cgi?id=1329752 The goal in 53 is to allow e10s to expand to all users, unless they have add-ons marked specifically MPC=False (not multiprocess compatible) So, it's a nice thing to investigate on alphas, but not for the stable.
Also, in order to stop spending time on Mozilla's experiments, your effort should be targeted to conversion to out-of-process WebExtensions, compatible with e10s-multi.
-
Just to note this here: e10s in its current form probably brings some fingerprinting risks with it. e.g. users of accessibility tools won't have e10s enabled on Windows and macOS at least. Windows XP users with D3D9 support neither. mcs and brade found that
showModalDialog()is not available when e10s is enabled etc. Not sure whether we can do anything about that and whether we should. Replying to gk:
Just to note this here: e10s in its current form probably brings some fingerprinting risks with it. e.g. users of accessibility tools won't have e10s enabled on Windows and macOS at least. Windows XP users with D3D9 support neither. mcs and brade found that
showModalDialog()is not available when e10s is enabled etc. Not sure whether we can do anything about that and whether we should. Weird https://bugzilla.mozilla.org/show_bug.cgi?id=981796#c54: According to the current situation, we disabled this feature on 51.0 in some builds. Also The "dom.disable_window_showModalDialog" preference exists.-
There is
#if defined(XP_WIN) if (IsVistaOrLater()) { nsAdoptingCString channelName = Preferences::GetDefaultCString("app.update.channel"); if (channelName.EqualsLiteral("release") || channelName.EqualsLiteral("esr")) { gMultiprocessBlockPolicy = kE10sDisabledForOperatingSystem; return gMultiprocessBlockPolicy; } } #endif // XP_WINWe probably don't want to have it enabled in Win XP on
alphaordefaulteither. -
See as well the discussion in #21876 (moved).
Also NoScript's GUI feels itself bad in tbb-nightly (e10s on Win XP)
13:49:21.629 TypeError: win is null 1 Main.js:1088:11 ns.isGlobalHttps chrome://noscript/content/Main.js:1088:11 noscriptOverlay<.prepareMenu chrome://noscript/content/noscriptOverlay.js:727:35 noscriptOverlay<.onMenuShowing chrome://noscript/content/noscriptOverlay.js:69:5 onpopupshowing chrome://browser/content/browser.xul:1:1 openPopup chrome://global/content/bindings/popup.xml:50:15 noscriptOverlay<.openPopup chrome://noscript/content/noscriptOverlay.js:31:5 noscriptOverlay<.onUIOver/< chrome://noscript/content/noscriptOverlay.js:91:13-
Replying to gk:
We might want to have a FAQ entry or something explaining when e10s is not enabled. There are multiple multiProcessStatus.* items in
aboutSupport.propertiesexplaining reasons for enabling/disabling e10s.Some of the strings are no longer used. See: https://dxr.mozilla.org/mozilla-esr52/source/toolkit/xre/nsAppRunner.cpp#4826 (or search for
about:supportwithin nsAppRunner.cpp). -
Okay, the ticket for explaining when e10s is disabled in Tor Browser is #22274 (moved). Closing this one.
Trac:
Status: new to closed
Resolution: N/A to fixed