On Wed, Apr 24, 2019 at 2:21 PM David Major <dma...@mozilla.com> wrote:
> 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". > I'm concerned about the impact of a gradual degradation of the e10s experience and an ambiguous bar as to exactly how much work developers are expected to do to support it. It's effectively going to be a Tier-3 platform with no owner. > > 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. > I think the tradeoff boils down to (a) how many developers are using non-e10s debugging, with what frequency, versus (b) how much ongoing maintenance work is required across various components to keep non-e10s working. We all have intuition about these things, but I doubt we have hard data. I'm open to the argument that my proposal is too aggressive. We could certainly try the muddle approach for a while and see how it goes, and how often 1proc breaks in practice. I don't think we can justify continuing to run the full suite of 1proc tests as tier-1, but we could potentially run a few smoketests, which might keep the builds usable enough for debugging. If anyone is chomping at the bit to remove 1proc support from their module, please speak up. > > 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
