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 <ehsan.akhg...@gmail.com> wrote: > 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
