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 C-C TB mochitest
execution, contain conflicting stetting.
pref("browser.tabs.remote.autostart", {true|false});
The value is either true or false. Not consistent. In mochitest of C-C
TB, there may be a few very browser-like test. In those cases,
|browser.tabs.remote.autostart| can be true? However, if we ALWAYS need
to set the value for false for C-C TB mochitest,
>> // No e10s in Thunderbird for now.
>> pref("browser.tabs.remote.autostart", false); <=== This
we may be in a big trouble.
I observe that there are multiple lines to set
"browser.tabs.remote.autostart" in a user.js with different
setting. Of course, the last one sets the used value. Inquiring mind
wants to know how the setting is composed (presumably concatenate some
settings prepackaged in user.js files in test file directories? I have
noticed that there are user.js files in test directory. See (3)
below.) Clear description of how the run-time user.js is created for
each test during c-c TB mochitest run would be desirable.
In any case, I DID find cases where sub-tests (albeit web
browser-oriented?) run with a user.js with
|pref("browser.tabs.remote.autostart", true);| which may not sit well
for C-C thunderbird binary.
I have a nagging feeling that this bad setting may/could be one of the
causes of the failure to run valgrind because we need more than 1500+
threads to run the C-C TB mochitest(!)
(2) user.js file under MOZ_OBJ/temp,
/NEW-SSD/moz-obj-dir/objdir-tb3/temp/user.js, does NOT set
|pref("browser.tabs.remote.autostart", false);|
I wonder if this user.js in MOZ_OBJ directory is used or not during C-C
mochitest. If it is used, I think we are in a big trouble since it does
not set the value to false.
(3) There are a few |user.js| files with conflicting settings in the
test directories. Some set the pref to false, but some set to true.
I hope they are used appropriately. Since the C-C mochitest works more
or less, I believe they are used correctly, but a clear
documentation/explanation of how each is used and how each test creates
user.js dynamically from the prepackaged user.js for TB
mochitest would be desirable.
--- end quote ---
So if the testing of web browser function in C-C TB mochitest runs with
e10s enabled, then it is not testing the real world usage because
e10s is disabled for TB usually.
(OTOH, it is hard to believe that if TB needs to disable e10s, the
built-in web renderer in TB can run with e10s enabled without disrupting
the behavior of the rest of the code. Something is screwed up in
dynamically generated mochitest user.js )
I hope someone familiar with C-C TB mochitest investigates this and
figures if the current state of the affairs is correct or not.
Chiaki
On 2020/06/18 16:46, Magnus Melin wrote:
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 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:
https://searchfox.org/comm-central/rev/e62a0af3cba6e1c65b2d4be02d3fefce88cf3f8f/mail/app/profile/all-thunderbird.js#654
Of course, if TB needs this configuration then that may complicate
removing support for non-e10s entirely...
~ Gijs
On 10/06/2020 19:56, Emilio Cobos Álvarez wrote:
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 <dtowns...@mozilla.com>
wrote:
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 disable e10s.
On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch
<gijskruitbo...@gmail.com
wrote:
(Copied to fx-dev; Replies to dev-platform please.)
Hello,
Just over a year ago, I started a discussion[0] about our support for
disabling e10s. The outcome of that was that we removed support for
disabling e10s with a pref on Desktop Firefox with version 68, except
for use from automation. We kept support for using the environment
variable. [1]
Last week, we released Firefox 77, which turned out to break all
webpages sent using compression (like gzip) if you had disabled e10s
using this environment variable. [2]
So here we are again. I'd like to propose we also stop honouring the
environment variable unless we're running tests in automation. We
clearly do not have sufficient test coverage to guarantee basic
things
like "the browser works", it lacks security sandboxing, and a
number of
other projects require it (fission, gpu process, socket process,
...),
so I think it's time to stop supporting this configuration at all.
I hope to make this change for the 79 cycle. I'm open to arguments
either way about what to do for 78 esr (assuming the patch for 79
turns
out to be simple; the work to remove the pref had a number of
annoying
corner-cases at the time).
Please speak up if you think that this plan needs adjusting.
~ Gijs
[0]
https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
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
