Re: Intent to enable e10s by default when running tests locally

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,

Re: Intent to enable e10s by default when running tests locally

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?

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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?

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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 >

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

+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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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

Re: Intent to enable e10s by default when running tests locally

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