Hey folks, For Desktop, I don't believe there are any normal conditions under which our users will have e10s disabled. [1] is where the decision gets made, and it looks like these days, the only thing that will disable e10s is if the user sets `browser.tabs.remote.autostart` to false themselves, or if a MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of those are ever set by Mozilla these days.
There was a case a few months back where e10s was disabled for users with certain screen readers back for Firefox 60. Since that time, those screen readers have updated to become more stable with e10s enabled. Unfortunately, I don't have a reference to the bug(s) where that occurred, but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last supported version where this e10s-disabling occurs on Desktop. So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR, e10s-disabled is not a mode that we ship to any of our users. We can trigger it by pref flips or environment variables, but that's it. Mobile is another story - according to the fine folks in #mobile, Fennec still runs Gecko in non-e10s mode. To circle back to Gijs's questions: 1. do we still consider running desktop Firefox with e10s disabled a > supported configuration? > Outside of Firefox 60 ESR, no, I don't believe so. 2. Will we need to turn it off on esr68 in the same circumstances where > that happens on esr60? > According to yzen from the Accessibility team, no, we won't. 3. If the answer to either of the previous 2 questions is 'yes', do we > think it's acceptable not to run desktop tests on the configuration? > Answers are no. 4. If the answer to both (1) and (2) is 'no', can we remove support for > the pref and running desktop Firefox without e10s ? Some of the > codepaths are not unified and so there is effectively dead code that > we're lugging around for what would be no reason. (Note: a significant > proportion isn't dead because even in e10s, we load some > browser-provided content in parent process, ie a tab's browser is not > always remote/non-same-process -- but even so, there's a bunch of stuff > that keys off gMultiProcessBrowser that could be removed.) > Yes, I believe that stuff is probably safe to remove at this point, as long those changes don't assume e10s support on Fennec. -Mike [1]: https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002 On Tue, 23 Apr 2019 at 13:35, Dave Townsend <dtowns...@mozilla.com> wrote: > Is there still a configuration (ignoring hidden prefs) that can cause a > user to end up using non-e10s? If so we should turn these tests back on. > > On Tue, Apr 23, 2019 at 8:25 AM Joel Maher <jma...@mozilla.com> wrote: > > > Here is where we initially turned on non-e10s tests for win7: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371 > > > > and then moved to linux32: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 > > > > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree- these > > run this way as they do not work with e10s=true. I suspect the > > mochitest-chrome is by design and a11y is a bug. > > > > -Joel > > > > > > On Thu, Apr 18, 2019 at 5:47 PM Bobby Holley <bobbyhol...@gmail.com> > > wrote: > > > > > If we're not testing it, we shouldn't be shipping it to users. It would > > be > > > great if someone familiar with the esr60 situation could confirm that > we > > > don't plan to repeat it for esr68. It would also be great if someone > > could > > > explain the rationale for running some, but not all of the suites in > > 1proc > > > mode. > > > > > > Separately, I know some engineers disable e10s locally as a hack to > > > simplify debugging (e.g [1]). The 1proc mochitest+xpcshell+reftest jobs > > > currently on automation are probably sufficient to continue support for > > > this use-case, but if we turn those off, we should consider this > workflow > > > and how much we're willing to do to preserve it. > > > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1530977#c0 > > > > > > On Wed, Apr 17, 2019 at 5:40 AM Gijs Kruitbosch < > > gijskruitbo...@gmail.com> > > > wrote: > > > > > >> Hello, > > >> > > >> Today it came to my attention that there are no 1proc (non-e10s) > browser > > >> mochitests running anymore. > > >> > > >> It appears they were disabled in > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 in early 2018, > > >> which is somewhat odd because it looks like the bug talks about > linux32, > > >> but removed the win7 non-e10s browser chrome tests. At the time, > > >> linux64-jsdcov was still non-e10s, but that was changed in > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1451849, a bit later in > > >> 2018 . > > >> > > >> This was a surprise to me because there is still a bunch of in-tree > > >> desktop browser frontend code that is supposed to work if e10s is > turned > > >> off using the relevant pref. But we apparently have no automated test > > >> coverage for this [so one assumes that some of it does not, in fact, > > >> work anymore...]. The last discussion about e10s test support that I'm > > >> aware of dates back to 2017. I do not recall there being public > > >> discussion about turning off these tests when it did happen (though of > > >> course, being human, it's possible I missed or forgot about it). > > >> > > >> I'm aware we still turn off e10s on esr60 in some circumstances, and > > >> that on other channels the hidden pref can be used to do the same. > > >> > > >> Open questions that I'd like to ask: > > >> 1. do we still consider running desktop Firefox with e10s disabled a > > >> supported configuration? > > >> 2. Will we need to turn it off on esr68 in the same circumstances > where > > >> that happens on esr60? > > >> 3. If the answer to either of the previous 2 questions is 'yes', do we > > >> think it's acceptable not to run desktop tests on the configuration? > > >> 4. If the answer to both (1) and (2) is 'no', can we remove support > for > > >> the pref and running desktop Firefox without e10s ? Some of the > > >> codepaths are not unified and so there is effectively dead code that > > >> we're lugging around for what would be no reason. (Note: a significant > > >> proportion isn't dead because even in e10s, we load some > > >> browser-provided content in parent process, ie a tab's browser is not > > >> always remote/non-same-process -- but even so, there's a bunch of > stuff > > >> that keys off gMultiProcessBrowser that could be removed.) > > >> > > >> Thanks, > > >> Gijs > > >> _______________________________________________ > > >> dev-platform mailing list > > >> dev-platform@lists.mozilla.org > > >> https://lists.mozilla.org/listinfo/dev-platform > > >> > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
