This has now landed on central. The following suites are e10s by default
and require the --disable-e10s flag to run non-e10s:
* marionette
* mochitest (excluding chrome, a11y and android)
* reftest (excluding android)
* talos
* web-platform-tests
I also added some logging to marionette,
On 04/04/16 09:37 AM, Ehsan Akhgari wrote:
On Sun, Apr 3, 2016 at 11:51 PM, Blair McBride wrote:
Default options imply the default is somehow favoured over the
non-default. Which, for this, makes me wonder: Is getting tests passing on
non-e10s less important now?
On Sun, Apr 3, 2016 at 11:51 PM, Blair McBride wrote:
> Default options imply the default is somehow favoured over the
> non-default. Which, for this, makes me wonder: Is getting tests passing on
> non-e10s less important now?
>
Fennec doesn't use e10s, so at least for
My understanding is shipping e10s is the top priority, so I believe that
implies running tests there is (slightly) favoured.
But I like your idea for a dual mode. I'm on the fence whether it would
be a good default or not as it will double the time to run tests
locally, and many people likely
On Thursday 2016-03-24 12:51 -0400, Boris Zbarsky wrote:
> On 3/24/16 12:43 PM, Andrew Halberstadt wrote:
> >I'm not aware of work around this. If --debugger is completely busted
> >with e10s, I could potentially make --debugger imply --disable-e10s
> >until it gets fixed. Is there a bug on file?
Karl Tomlinson wrote:
> I had guessed that documents from "chrome:" would run in the browser
> process (by default, at least), but is it all determined by
> attributes on a browser element?
It's more complicated than that. See
Felipe G. writes:
> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
> using --e10s. Other tabs and/or windows opened
Slightly related: since bug 1253233 landed (well, hum, the most important parts
of it), it’s possible to add fully functioning
elements to mochitest-chrome test windows. Since many chrome test use the
pattern of adding a browser element and do stuff with it upon load, I thought
this might be
I have already filed bug 1255095 about this, as you are far from the first
person to be confused by this!
Andrew
On Thu, Mar 24, 2016 at 11:59 AM, Ehsan Akhgari
wrote:
> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
>
>> Yeah, --e10s enables e10s
Yeah, that sounds like another good outcome of replacing --e10s with
--disable-e10s.
On Thu, Mar 24, 2016 at 3:59 PM, Ehsan Akhgari
wrote:
> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
>
>> Yeah, --e10s enables e10s in the browser for
On Thu, Mar 24, 2016 at 2:10 PM, Felipe G wrote:
> Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
> the test harness is a .xul file opened in a tab, and that runs that tab as
> non-remote, so for most tests it ends up testing the same thing as not
>
Yeah, --e10s enables e10s in the browser for mochitest-chrome. However,
the test harness is a .xul file opened in a tab, and that runs that tab as
non-remote, so for most tests it ends up testing the same thing as not
using --e10s. Other tabs and/or windows opened manually by the test would
be
On 2016-03-24 1:25 PM, Andrew McCreight wrote:
> One potential sticking point is mochitest-chrome. It currently does not
>> get run in e10s in CI, so local configuration should mirror this.
>> However, since --e10s is being removed, this means it would be
>> impossible to run mochitest-chrome in
Afaict, ./mach mochitest -f chrome --e10s enables e10s. At least the
python side isn't overriding that default. Maybe there's some JS code
somewhere that overrides it.
But if the intent is for mochitest-chrome to never run with e10s enabled
anyway, then I guess not having that option isn't a big
On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:
> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.
Great!
[some text deleted]
One potential
We fork a process to test gfx early on so 'set follow-for-mode child'
might end up following that.
'set detach-on-fork off' will keep you attached to everything though.
-Jeff
On Thu, Mar 24, 2016 at 1:21 PM, Paul Adenot wrote:
> Do we know whether `set follow-fork-mode child` in
Do we know whether `set follow-fork-mode child` in gdb would work ? If
not, can we fix it ? It would be a pretty good experience for most
developers that only care about the child.
Paul.
On Thu, Mar 24, 2016, at 06:05 PM, Aaron Klotz wrote:
> I know that most people aren't debugging e10s on
I know that most people aren't debugging e10s on Windows, but if you
are, here's a protip (provided that you are using WinDbg):
If you include the "-o" option in the debugger args, WinDbg will
automatically attach itself to all child processes that are started by
the chrome process. No
+1. The MOZ_DEBUG_CHILD_PROCESS hack is pretty arcane.
On Thu, Mar 24, 2016 at 9:30 AM, Boris Zbarsky wrote:
> On 3/24/16 12:15 PM, Andrew Halberstadt wrote:
>
>> If you have any concerns or know of other suites that should explicitly
>> *not* be run with e10s enabled by
On 3/24/16 12:43 PM, Andrew Halberstadt wrote:
I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?
I don't know of one.
It's not that it's busted per se, it's
I'm not aware of work around this. If --debugger is completely busted
with e10s, I could potentially make --debugger imply --disable-e10s
until it gets fixed. Is there a bug on file?
I also forgot to mention that command defaults are likely coming soon,
so once bug 1255450 lands you'll be able
On 3/24/16 12:15 PM, Andrew Halberstadt wrote:
If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.
Do we have any plans for making --debugger not completely useless when
running tests in e10s mode? There are
Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.
The implication is that the --e10s flag will be renamed to
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to
run
23 matches
Mail list logo