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.
Other opinions?
On Tue, Apr 23, 2019 at 1:30 PM Mike Conley <
mco...@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.)
>>
>