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
