On Thu, Mar 24, 2016 at 2:10 PM, Felipe G <fel...@gmail.com> 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 > using --e10s. Other tabs and/or windows opened manually by the test would > be remote. >
D'oh, I have been working on this stuff and I didn't realize that's the case (I was operating as if a passing mochitest-chrome when run in e10s actually works with e10s). That's extremely confusing. :( Should we refuse to accept --e10s when running mochitest-chrome to help avoid this confusion? > > On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> 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 e10s without modifying source >> >> files. Maybe this just needs some argparse hackery. >> >> >> > >> > My impression was that mochitest-chrome doesn't actually run with e10s, >> > even when you specify the flag. Is that not correct? >> >> No. You currently can force it to run in e10s with --e10s like other >> mochitest variants. >> >> _______________________________________________ >> firefox-dev mailing list >> firefox-...@mozilla.org >> https://mail.mozilla.org/listinfo/firefox-dev >> > > -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
