On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley <bobbyhol...@gmail.com> wrote: > > Thanks Mike! > > So Fennec is the last remaining non-e10s configuration we ship to users. > Given that Fennec test coverage is somewhat incomplete, we probably want to > keep running desktop 1proc tests until Fennec EOL. We don't strictly need > the browser-chrome tests, but we should probably avoid intentionally > breaking non-e10s browser-chrome as long as engineers may still need to > debug non-e10s test failures. > > After Fennec EOL, we basically have two options: a clean break where we rip > out non-e10s support entirely, or a more muddled approach where we > halfheartedly keep it working as a handy engineering hack as long as is > practical. I think we should do the former. > > I don't want to downplay the handiness - being able to test and debug the > browser in a single process can eliminate complexity and non-determinism, > and save a lot of time. But at some point there's going to be a piece of > core functionality that's too much work to keep supporting under non-e10s - > and agonizing over that threshold on an ongoing basis is not a good use of > anyone's time.
Why not have the conversation when such a piece of core functionality arises? It's a much more convincing argument when you can say "non-e10s needs to go away in order to support X". In the meantime, single process debugging is a tremendous saver of time and hassle, and we'd need a great reason to disable it. I'm not convinced that one currently exists. > Other opinions? > > On Tue, Apr 23, 2019 at 1:30 PM 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
