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
