Slightly related: since bug 1253233 landed (well, hum, the most important parts of it), it’s possible to add fully functioning <browser remote=“true”/> 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 a nice pattern to reuse. (Run the current test code twice, once for each browser element.)
You can also use Task.jsm and ContentTask.jsm tasks just like you’re used to from mochitest-browser tests. You can also use Assert.* assertions _inside_ frame scripts spawned by ContentTask. Example that converts a mochitest-chrome test to use ContentTask: https://hg.mozilla.org/mozilla-central/rev/2aad094c7cf8#l1.34 <https://hg.mozilla.org/mozilla-central/rev/2aad094c7cf8#l1.34> Just FYI, have fun! Mike. > On 24 Mar 2016, at 20:27, Andrew McCreight <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> > wrote: > >> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G <[email protected]> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/firefox-dev >>>> >>> >>> >> >> >> -- >> Ehsan >> > _______________________________________________ > dev-platform mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
