Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
Just a quick follow-up - yzen got back to me - here's the bug that tracked disabling e10s in Firefox 60 for older screen readers: https://bugzilla.mozilla.org/show_bug.cgi?id=1489605 On Tue, 23 Apr 2019 at 16:30, Mike Conley 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 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 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 >> > 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
Firefox Update with BITS download
Exciting changes are coming to Firefox Update on Windows! We have added the ability to download updates via the Windows BITS component. This change will allow Firefox to continue downloading an update after Firefox has been closed. Note that this does not allow downloads to be started without Firefox (but that feature is in the works!) This feature is already on Nightly, but is turned off by default. It can be enabled by setting the "app.update.BITS.enabled" pref to true. Soon, we plan to test this feature by turning it on for a randomly-selected half of Nightly users. This will be done by setting the default value of the pref, so the decision can still be overridden by changing the pref value manually. If you have a problem with this feature, you can file an application update bug blocking Bug 1540193: https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit=Application+Update=1540193 -bytesized ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
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 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 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 > > 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
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
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 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 > 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
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
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 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 > 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
