Opened 23 months ago

Closed 19 months ago

Last modified 19 months ago

#21432 closed task (fixed)

Make a plan on how to deploy e10s in Tor Browser

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-e10s, TorBrowserTeam201705, tbb-7.0-must
Cc: mcs, brade, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (19)

comment:1 Changed 22 months ago by 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.

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.

comment:2 Changed 22 months ago by arthuredelstein

Cc: arthuredelstein added

comment:3 in reply to:  1 Changed 22 months ago by gk

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.

comment:4 in reply to:  description Changed 22 months ago by cypherpunks

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.

Last edited 20 months ago by cypherpunks (previous) (diff)

comment:5 Changed 22 months ago by gk

Keywords: tbb-7.0-must added

comment:6 Changed 22 months ago by gk

Keywords: TorBrowserTeam201703 added; TorBrowserTeam201702 removed

Moving tickets to March

comment:7 Changed 22 months ago by 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.

comment:8 Changed 22 months ago by gk

We might want to have a FAQ entry or something explaining when e10s is not enabled. There are multiple multiProcessStatus.* items in aboutSupport.properties explaining reasons for enabling/disabling e10s.

comment:9 in reply to:  7 Changed 22 months ago by cypherpunks

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.

comment:10 Changed 21 months ago by gk

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_WIN

We probably don't want to have it enabled in Win XP on alpha or default either.

comment:11 Changed 21 months ago by gk

Keywords: TorBrowserTeam201704 added; TorBrowserTeam201703 removed

Moving tickets over to April

comment:12 Changed 21 months ago by gk

Keywords: tbb-7.0-must-alpha added; tbb-7.0-must removed

Getting this on our radar for alpha release in less than two weeks.

comment:13 Changed 21 months ago by gk

See as well the discussion in #21876.

comment:14 Changed 21 months ago by cypherpunks

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

comment:15 in reply to:  8 Changed 21 months ago by mcs

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.properties explaining 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:support within nsAppRunner.cpp).

comment:16 Changed 20 months ago by gk

Keywords: tbb-e10s added

Adding e10s keyword to track multiprocess related bugs.

comment:17 Changed 20 months ago by gk

Keywords: TorBrowserTeam201705 added; TorBrowserTeam201704 removed

Moving our tickets to May 2017.

comment:18 Changed 19 months ago by gk

Resolution: fixed
Status: newclosed

Okay, the ticket for explaining when e10s is disabled in Tor Browser is #22274. Closing this one.

comment:19 Changed 19 months ago by gk

Keywords: tbb-7.0-must added; tbb-7.0-must-alpha removed

We are beyond the alpha testing. Moving tickets for tbb-7.0-must.

Note: See TracTickets for help on using tickets.