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
