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
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_b
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, o
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 Fire
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 no
5 matches
Mail list logo