Enable MojoJS when testing Chrome

[Hexcles]

Fixes #81

This is the only missing requirement to run WebUSB tests on Chrome (as confirmed in https://crbug.com/821496#c19). WebUSB has a public test API interface but the fake device relies on browser-specific implementation (in Chrome's case, Mojo JS); also see this comment.

@foolip , I'd like your stamp for this as it'd introduce yet another difference between wpt.fyi and running wpt run directly (similar to what we've already done for media stream).
@jugglinmike , PTAL if I missed anything.

[rakuco]

FTR, this is also a requirement for other tests besides WebUSB such as the sensors APIs.

[jugglinmike]

Could you update the comment that precedes this (or insert this argument with a separate statement)?

@jgraham as @Hexcles notes, this represents further divergence from the default wpt run invocation. You previously expressed a desire to avoid this, so I wanted to keep you posted.

For my part, I'd rather see the effort invested in testing strategies that could be shared by all browsers and that would promote authenticity. We've discussed that for getUserMedia, but I still don't have a sense for how feasible it might be for WebUSB, Sensors, or WebBluetooth. Maybe folks following this issue could share their perspective.

[jgraham]

Yes, in general I would prefer this kind of thing go into wptrunner rather than being enabled at a higher layer. Otherwise it's difficult to reproduce the results on wpt.fyi.

Re: the general media test strategy, I would be interested in getting input from gecko developers like @padenot and @jyavenard.

[Hexcles]

Alternatively, I can send a PR to wptrunner to add all these flags when testing Chrome, and then remove the existing media-stream flags here. To some extent, that would be similar to Firefox which downloads and uses a prefs bundle for testing.

[padenot]

Re: the general media test strategy, I would be interested in getting input from gecko developers like @padenot and @jyavenard.

Reading the document, I can say that Gecko has started to use virtual devices (not necessarily drivers, this depends on various things), and is going to continue in this direction. Having this be a bit more standard sounds like a good idea. It's likely that in practice, various implementations already use the same well known solutions (v4l2loopback, PulseAudio monitor devices, SoundFlower, Virtual Audio Calble, etc...). We're also using internal device mocks as part of the Gecko test code, but that's something else.

I'd be happy to be cc-ed to any discussion on the topic, without derailing the current conversation which is about something else.