Just a quick follow-up - yzen got back to me - here's the bug that tracked disabling e10s in Firefox 60 for older screen readers:
https://bugzilla.mozilla.org/show_bug.cgi?id=1489605 On Tue, 23 Apr 2019 at 16:30, Mike Conley <mcon...@mozilla.com> wrote: > 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
