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
