Since there were no further concerns voiced to the final proposal I've gone
ahead and landed the change in
https://bugzilla.mozilla.org/show_bug.cgi?id=1653384. To be respected you
must now set
the MOZ_FORCE_DISABLE_E10S environment variable to the full application
version. `mach run
I think I have found an inconsistency in TB's pref setting during
mochitest regarding e10s.
The gory detail is in
https://bugzilla.mozilla.org/show_bug.cgi?id=1629433#c10
Major find (excerpt from the above bugzilla.)
--- begin quote ---
1) Dynamically generated user.js files during tests of
Currently Thunderbird doesn't work with e10s.
Longer term I'm assuming we'll need to do necessary adaptions so that we
can - but I suspect this is a slightly larger project...
I've filed bug 1646648 to track this work.
-Magnus
On 2020-06-10 22:05, Gijs Kruitbosch wrote:
I can't speak for
Having read all the responses here, I guess an adjusted proposal would
be to switch to requiring the variable to be set to the build's version.
Does that seem like it'd address your concerns?
There were two other points raised that I wanted to briefly respond to:
What does this proposal mean
On Wed, Jun 10, 2020 at 11:13 PM James Teh wrote:
> In general, this obviously makes a lot of sense. However, because there is
> so much extra complication for accessibility when e10s is enabled, I find
> myself disabling e10s in local opt/debug builds to isolate problems to the
> core a11y
On 6/10/2020 2:09 PM, tom...@gmail.com wrote:
* GeckoView still supports running in non-e10s mode, and inability to mimic
that environment on desktop builds would complicate writing code that works on
android.
GeckoView's only technical reason for supporting non-e10s was FxR, but
they have
I can't speak for what TB development plan is.
One thing I observe as an occasional submitter of TB patches is this.
Thunderbird ditched |mozmill| test December 2019, and switched to
mochitest in place of mozmill test.
Unfortunately, valgrind no longer works locally for mochitest.
This is
In general, this obviously makes a lot of sense. However, because there is
so much extra complication for accessibility when e10s is enabled, I find
myself disabling e10s in local opt/debug builds to isolate problems to the
core a11y engine (vs the a11y e10s stuff). The ability to do this was
I agree about not shipping this to our users, but I see several needs to keep
this option for developers working on Firefox:
* GeckoView still supports running in non-e10s mode, and inability to mimic
that environment on desktop builds would complicate writing code that works on
android.
* As
I can't speak for Thunderbird's plans, but either way these plans
shouldn't affect them and is restricted to desktop Firefox; the pref
still works there:
https://searchfox.org/mozilla-central/rev/4bb2401ecbfce89af06fb2b4d0ea3557682bd8ff/toolkit/xre/nsAppRunner.cpp#5020-5024
, and they set it:
I agree that it's a bad idea for users to be running permanently with this
setting on their daily driver browsers.
But the environment variable has been a huge productivity enhancer to
reduce my mental load when setting up an extra-hairy debug session or
taking system traces.
I wish we could
I was asked off-list why I'm not suggesting we remove support for the
environment variable entirely (ie why keep it for tests). That's a good
question, so I will attempt to address it.
I think that's a laudable goal, but it's more work. Practically
speaking, AIUI valgrind still runs with e10s
What is the situation of Thunderbird? I think they don't have e10s enabled
yet, and it may be worth at least knowing what their plans are.
-- Emilio
On Wed, Jun 10, 2020, 8:44 PM Dave Townsend wrote:
> Non-e10s is such a different environment that I don't think we have any
> hope of keeping
Non-e10s is such a different environment that I don't think we have any
hope of keeping it working without running the full test suite in that mode
and I don't think anyone wants to do that. Now that this has started
breaking I think it is actively harmful to our users for us to allow them
to
14 matches
Mail list logo
