sable-e10s` has been updated to do this
automatically.
On Wed, Jun 17, 2020 at 1:45 PM Gijs Kruitbosch
wrote:
> 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'
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
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 wrot
posal mean for ./mach run --disable-e10s ?
In the adjusted proposal, this would set the right env var, as it does
today, so there should be no difference.
* particularly on Windows where even basic `printf` and `dump` from the child
process don't show up in the console.
As I have s
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
&g
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
ay be able to run under
valgrind during mochitest if this
e10s setting is properly handled. Right now, TB under valgrind during
mochitest starts more than 1500 threads (too many IMHO), but less than
5000 threads (I have not figured out exactly how many threads are
required), and valgrind barfs.
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
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
setting, like maybe you'd have to set the env var equal to the
build ID or today's date?
On Wed, Jun 10, 2020 at 2:44 PM Dave Townsend 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 te
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
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
>
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 all
(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
(Cross-post: m-d-platform and firefox-dev)
Hello,
(If you don't care about turning off e10s, you can stop reading.)
At the end of last week I landed changes in
https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
that may affect how you turn off e10s. The broad aim was to ensure that
we
On 01/05/2019 19:01, Bobby Holley wrote:
This thread is getting long, so here's a quick recap:
* It it well-understood that a number of developers use --disable-e10s as a
debugging aid, so more +1s to that effect aren't needed.
* The "please speak up" is aimed at developers
On Wed, Apr 24, 2019 at 11:40 PM Jean-Yves Avenard
wrote:
>
> Before non-e10s support is removed, I'd love to see better
> development/debugging tools, particularly on Windows added to help our
> workflow.
Was there anything in particular that you had
On Wed, May 1, 2019 at 10:27 AM Jonathan Kew wrote:
> On 01/05/2019 17:29, Randell Jesup wrote:
> > Jean-Yves writes:
> >>> If anyone is chomping at the bit to remove 1proc support from their
> module,
> >>> please speak up.
> >>
> >> I am o
On 01/05/2019 17:29, Randell Jesup wrote:
Jean-Yves writes:
If anyone is chomping at the bit to remove 1proc support from their module,
please speak up.
I am one of those developers that find non-e10s essential to debug core
features.
I've depended on using non-e10s for ages as well.
Jean-Yves writes:
>> If anyone is chomping at the bit to remove 1proc support from their module,
>> please speak up.
>
>I am one of those developers that find non-e10s essential to debug core
>features.
I've depended on using non-e10s for ages as well. Most of my debug
On Thu, Apr 25, 2019 at 1:58 PM Bobby Holley wrote:
> As long as we're certain that we won't ship Fennec past ESR68,
>
The timeline was left vague. Ideally I assume we'd like to migrate Fennec
folks to Fenix before ESR68 EOL, but if it's not ready there's no reason we
have to stop shipping a 68-
, in order:
> (1) Remove support for the e10s pref, per Gijs' suggestion above.
> (2) Define and launch a small "1proc-smoketest" job, based on
> mochitest-plain, with a handful of tests across various components to
> verify that things mostly work.
> (3) Turn off the
This was announced last night:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/k-irJtmCcqg
On Thu, Apr 25, 2019 at 5:34 PM Botond Ballo wrote:
> On Thu, Apr 25, 2019 at 4:58 PM Bobby Holley
> wrote:
> > we won't ship Fennec past ESR68
>
> That's news to me. Was this announced som
On Thu, Apr 25, 2019 at 4:58 PM Bobby Holley wrote:
> we won't ship Fennec past ESR68
That's news to me. Was this announced somewhere? Is there a discussion
you could point me to?
Thanks,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.
On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote:
>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
>>>> wrote:
>>>>
>>>>> >
>>>>>> > Thanks Mike!
>>>>>> >
;> wrote:
>>>
>>>> >
>>>>> > Thanks Mike!
>>>>> >
>>>>> > So Fennec is the last remaining non-e10s configuration we ship to
>>>>> users.
>>>>> > Given that Fennec test coverage is somewhat
On Thu, Apr 25, 2019 at 12:12 PM Bobby Holley wrote:
> On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
>> wrote:
>>
>>> >
>>>> > Thanks Mike!
>>>> >
>&
On 25/04/2019 17:12, Bobby Holley wrote:
On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote:
On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
wrote:
Thanks Mike!
So Fennec is the last remaining non-e10s configuration we ship to
users.
Given that Fennec test coverage is somewhat incomplete
On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote:
>
>
> On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
> wrote:
>
>> >
>>> > Thanks Mike!
>>> >
>>> > So Fennec is the last remaining non-e10s configuration we ship to
>>> us
On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley wrote:
> >
>> > 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
>&g
On Thu, Apr 25, 2019, at 7:55 PM, Gijs Kruitbosch wrote:
> Ideally, I think the debugging usecase would be better served by a more
> barebones "here's a docshell that will load arbitrary content off our
> trusted localhost server in 1 process" type app than by making desktop
> firefox run these
On 24/04/2019 18:39, Bobby Holley wrote:
Thanks Mike!
So Fennec is the last remaining non-e10s configuration we ship to users.
Well, or anything where a user (or malicious actor) has turned off e10s
using the pref which is now hidden (but wasn't in the past, and for
which we act
> On 25 Apr 2019, at 8:49 am, Bobby Holley wrote.
>>
>
> I think the tradeoff boils down to (a) how many developers are using
> non-e10s debugging, with what frequency, versus (b) how much ongoing
> maintenance work is required across various components to keep non-e
gt; > > > 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
On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote:
> On Wed, Apr 24, 2019 at 2:21 PM David Major wrote:
>
> > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
> > wrote:
> > >
> > > Thanks Mike!
> > >
> > > So Fennec is the
On Wed, Apr 24, 2019 at 2:21 PM David Major wrote:
> On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley
> wrote:
> >
> > Thanks Mike!
> >
> > So Fennec is the last remaining non-e10s configuration we ship to users.
> > Given that Fennec test coverage is somewh
On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley wrote:
>
> 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.
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
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 be
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 thems
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.mozil
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
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 w
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
This has now landed. So to re-iterate, if you see a "-1proc" suffix in the
task symbol that means it is running with e10s disabled. Otherwise e10s is
enabled. This symbol change will ride the trains (so you'll still see
"-e10s" on other branches for the time being).
On
I had about 5 independent suggestions of "-sp" and I agree that it is much
better than "-fc". But another idea that came out of these conversations
was "1proc" which also ticks all the boxes (only being a tiny bit longer
than "e10s") and being even clearer t
On 09/04/2019 20:44, Andrew Halberstadt wrote:
Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:
1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to
Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:
1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered o
Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit :
Hi everyone,
Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s&qu
Hi everyone,
Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task labels
and
treeherder symbols
It's tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1515702 - we
should be backing it out soon.
To solve it immediately, you can add --disable-hardening
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
เมื่อ วันอังคารที่ 5 พฤษภาคม ค.ศ. 2015 5 นาฬิกา 29 นาที 54 วินาที UTC+7, Leman
Bennett (Omega X) เขียนว่า:
> Inquiring minds would like to know.
>
> At the moment, e10s tabs is still somewhat slower than non-e10s.
> Multiple content processes would go a long way for mor
On Wed, Oct 18, 2017 at 3:22 PM, Justin Dolske wrote:
> On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote:
>
>>
>> One more thing to point out: with the removal of e10srollout, I also
>> removed the code that would disable e10s if we detected a
>> non-multiproce
On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote:
>
> One more thing to point out: with the removal of e10srollout, I also
> removed the code that would disable e10s if we detected a
> non-multiprocessComptaible extension. We are entirely relying on the addon
> manager to re
Hello everybody,
I'm in the process of landing a change in bug 1406212 [1] that changes the
way that we handle enabling or disabling of e10s and e10s-multi. This
change will ride the trains, so Firefox 58 will be the first version with
the simplified logic.
To recap the current situatio
;t "mochitest-media" (and other non-e10s
versions) be not-run by default, unless you specify it explicitly in -u ?
--
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists
be
faster- it will make it better for all of us :)
On Fri, Sep 8, 2017 at 5:40 PM, Ben Kelly wrote:
> Joel,
>
> Is there an easy way for me to run non-e10s tests on linux? We often use
> "t-style" try pushes where we only run tests on one platform. Restricting
> non-e
Joel,
Is there an easy way for me to run non-e10s tests on linux? We often use
"t-style" try pushes where we only run tests on one platform. Restricting
non-e10s to win7-debug means I either need to run tests on multiple
platforms or use windows for the "t-style". I don&#
If you've used RUST_LOG to enable logging for Rust modules, but were hoping
you could filter down to child processes only, bug 1390736 now allows you
to use RUST_LOG_CHILD to target them. This has been helpful for several of
us working on Stylo.
To use, just replace RUST_LOG with RUST_LOG_CHILD an
On Wed, Aug 30, 2017 at 1:16 AM, Kartikaya Gupta wrote:
> rr works just fine with multiple processes. Once you have a recording
> you can use `rr ps` to show all the process that were recorded and `rr
> replay -p ` to attach to a particular process. You can combine -p
> with -g as Cameron mention
On 08/29/2017 03:16 PM, Kartikaya Gupta wrote:
> Once you have a recording
> you can use `rr ps` to show all the process that were recorded and `rr
> replay -p ` to attach to a particular process.
I see, so `rr ps` was the bit whose existence I was missing :)
Thanks a lot!
-- Emilio
___
t is the best/easiest way to debug Firefox multi-process using rr?
>>
>> Right now I just disable e10s, but that's probably not a great long-term
>> solution...
>
> I do that too. :-)
>
> Mine is probably not the most efficient method, but most of the time I
>
On Tue, Aug 29, 2017, at 08:58 PM, Emilio Cobos Álvarez wrote:
> I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
> thought I'd ask before I actually need it.
>
> What is the best/easiest way to debug Firefox multi-process using rr?
>
> Right
Hi,
I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
thought I'd ask before I actually need it.
What is the best/easiest way to debug Firefox multi-process using rr?
Right now I just disable e10s, but that's probably not a great long-term
solution...
-- Emi
Yesterday I landed bug 1391371 which enabled non-e10s unittests on windows 7
debug. A few tests had to be disabled in order to do this. To keep track of
what we did and each of the test suites to evaluate, I have filed bug 1391350.
As a note we now have the following non-e10s tests running
two distinct implementations for the networking code.
> >> So if I understand the impact here right we just lost test coverage for
> >> probably a couple of thousand lines of code.
> > […]
> >
> >> I’m not sure how others do it, but our low level C++ unit tests
ere right we just lost test coverage for
>> probably a couple of thousand lines of code.
> […]
>
>> I’m not sure how others do it, but our low level C++ unit tests don’t have
>> an e10s mode at all.
>> Therefore we can’t simply delete the non-e10s WebRTC networkin
that are really aimed at Desktop or are cross-product but don't
run on e10s for (reasons).
2) Tests for features that are run in e10s on Desktop, but exercise
functional differences in non-e10s and don't run in Android.
For 1) running on Windows makes some sense because that'
On Wed, Aug 16, 2017 at 2:32 PM, Joel Maher wrote:
> Thanks everyone for chiming in here. I see this isn't as simple as a
> binary decision and to simplify things, I think turning on all non-e10s
> tests that were running for windows7-debug would give us reasonable
> coverag
Thanks everyone for chiming in here. I see this isn't as simple as a
binary decision and to simplify things, I think turning on all non-e10s
tests that were running for windows7-debug would give us reasonable
coverage and ensure that users on our most popular OS (and focus for 57)
have a s
On 08/15/2017 04:29 PM, jma...@mozilla.com wrote:
I would propose running these above tests on windows7-opt (we don't have these
running yet in windows 10, although we are close), and only running specific
tests which are not run in e10s mode, turning them off December 29th, 2017.
Ke
On 15/08/17 21:39, Ben Kelly wrote:
On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher wrote:
All of the above mentioned tests are not run on Android (well
mochitest-media is to some degree). Is 4 months unreasonable to fix the
related tests that do not run in e10s? Is there another time frame
.
[…]
I’m not sure how others do it, but our low level C++ unit tests don’t have an
e10s mode at all.
Therefore we can’t simply delete the non-e10s WebRTC networking code either
(without loosing a ton of test coverage).
If the networking code is only covered by C++ unit tests, there is
separate code
networking for not having
unified it’s networking code for e10s and non-e10s.
But when e10s got turned on I asked around if we could delete the non-e10s code
soon, I was told no.
So I assumed both technologies would stick around for some more time.
I’m not sure how others do it, but our low level C
I think Ben's argument has merit:
1. Even after Firefox 57, we will still be shipping a product in non-e10s
mode: Firefox for Android
2. If WPT (and potentially other suites) aren't being run in non-e10s mode,
it increases risk because we are shipping untested code paths to our user
On Tue, Aug 15, 2017 at 4:43 PM, Joel Maher wrote:
> This is a discussion about tests in e10s mode, not WPT on Android.
>
Yes. And android is our last tier 1 platform that requires non-e10s. I
think that makes it relevant to the discussion.
>
> What specific coverage are we mi
This is a discussion about tests in e10s mode, not WPT on Android.
What specific coverage are we missing by not running WPT in non-e10s mode
on desktop? When can we ensure we have that coverage in e10s mode? I
assume this is just making sure the tests that we have disabled on e10s
mode need to
On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher wrote:
> All of the above mentioned tests are not run on Android (well
> mochitest-media is to some degree). Is 4 months unreasonable to fix the
> related tests that do not run in e10s? Is there another time frame that
> seems mor
All of the above mentioned tests are not run on Android (well
mochitest-media is to some degree). Is 4 months unreasonable to fix the
related tests that do not run in e10s? Is there another time frame that
seems more reasonable?
On Tue, Aug 15, 2017 at 4:34 PM, Ben Kelly wrote:
> On Tue,
On Tue, Aug 15, 2017 at 4:29 PM, wrote:
> While there are many tests which individually are disabled or lacking
> coverage, these test suites have no non-e10s coverage:
> * web-platform-tests
> * browser-chrome
> * devtools
> * jsreftests
> * mochitest-webgl, mochitest
Thanks everyone for commenting on this thread. As a note, we run many tests in
non-e10s mode:
* android mochitest, reftest, crashtest, marionette,
* mochitest-chrome
* xpcshell
* gtest/cpptest/jittest
* mochitest-a11y
* mochitest-jetpack (very few tests remain)
While there are many tests which
We now have the ability to set prefs from a mochitest manifest (see bug
1328830 <https://bugzilla.mozilla.org/show_bug.cgi?id=1328830> and my
recent newsgroup post). We could refactor these tests into a special
non-e10s manifest that sets browser.tabs.remote.autostart=false and keep
runnin
d bring this information to a wider audience on
>> dev.platform so more developers are aware of the change.
>>
>> While we get some advantages to not running duplicated tests (faster try
>> results, less backlogs, fewer intermittent failures) there might be
>> compelli
I ran some scripts that I had to find out tests that are *fully* disabled
on e10s, and posted the results to
https://bugzilla.mozilla.org/show_bug.cgi?id=1376934
In summary:
mochitest-plain: 49 tests
browser-chrome: 15 tests
devtools: 86 tests
Note that the script evaluates the skip-if condition
about
how to hit the right process at the right time with the debugger. I never
switched back to non-e10s though since I don't trust that everything will
work the same and I don't think that should be the solution. Switching back
to single content process for debugging should come with le
On 8/8/17 6:40 PM, Blake Kaplan wrote:
What part of the current set-up is rocket science?
Debugging pageload. Especially pageload with no session history.
In multi, there's
definitely a problem figuring out which process is the active one (though
tooltips when hovering over tabs can help).
On 08/08/2017 06:51 PM, Blake Kaplan wrote:
L. David Baron wrote:
Has there been any additional effort to deal with tests that have
been disabled under e10s? This change means we've essentially
turned off a decent number of tests.
IIRC, the last time we talked about this, there was int
L. David Baron wrote:
> Has there been any additional effort to deal with tests that have
> been disabled under e10s? This change means we've essentially
> turned off a decent number of tests.
IIRC, the last time we talked about this, there was interest in either running
te
ens during pageload" is
> currently fairly rocket science to do in e10s mode; doubly so in
> e10s-multi. I haven't seen any concrete proposals for improving this
What part of the current set-up is rocket science? In multi, there's
definitely a problem figuring out which pro
On Wed, Aug 9, 2017 at 9:31 AM, Boris Zbarsky wrote:
Something as simple as "debug something that happens during pageload" is
> currently fairly rocket science to do in e10s mode; doubly so in
> e10s-multi. I haven't seen any concrete proposals for improving this
rr
On Tuesday 2017-08-08 14:12 -0700, jma...@mozilla.com wrote:
> As Firefox 57 is on trunk, we are shipping e10s by default. This means that
> our primary support is for e10s. As part of this, there is little to no need
> to run duplicated tests in non-e10s and e10s mode.
>
>
On 8/8/17 5:12 PM, jma...@mozilla.com wrote:
In bug 1386689, we have turned them off. There was some surprise in doing this
and some valid concerns expressed in comments in the bug.
Indeed. Given how often non-e10s mode needs to get used for debugging,
it's a little concerning to se
On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly wrote:
> On Tue, Aug 8, 2017 at 5:12 PM, wrote:
>
>> While we get some advantages to not running duplicated tests (faster try
>> results, less backlogs, fewer intermittent failures) there might be
>> compelling reasons to run som
On Tue, Aug 8, 2017 at 5:12 PM, wrote:
> As Firefox 57 is on trunk, we are shipping e10s by default. This means
> that our primary support is for e10s. As part of this, there is little to
> no need to run duplicated tests in non-e10s and e10s mode.
>
We still run android in n
As Firefox 57 is on trunk, we are shipping e10s by default. This means that
our primary support is for e10s. As part of this, there is little to no need
to run duplicated tests in non-e10s and e10s mode.
In bug 1386689, we have turned them off. There was some surprise in doing this
and
Hey all,
We've been running a series of e10s-multi experiments on the Beta
branch for a while now while watching memory use numbers, crash rates,
and other release criteria. After some positive returns from the first
round of testing we started talking about maybe releasing e10s-multi
in Fi
Hi,
On Thu, Apr 13, 2017 at 6:09 AM, Fischer Liu wrote:
> We are using dom.ipc.processCount to limit the count of process.
> After updating dom.ipc.processCount, do we still need to restart Firefox?
>
>
It depends. It will prevent any new processes to be launched that would go
beyond the new lim
Hi
We are using dom.ipc.processCount to limit the count of process.
After updating dom.ipc.processCount, do we still need to restart Firefox?
As I know in PreallocatedProcessManagerImpl::AllocateNow[2] and
PreallocatedProcessManagerImpl::RereadPrefs, there would read the pref to
check the max cou
s Peterson
wrote:
> On 2017-04-11 10:31 PM, Salvador de la Puente wrote:
>
>> How does this relate with Project Down and the end of Aurora channel? Will
>> be multi-e10s enabled when shifting from nightly to beta?
>>
>
> There is no connection between Project Dawn and en
1 - 100 of 391 matches
Mail list logo
