Robocop started as a way to write tests that were "Mochitest-like". That means there's an ambient web server (usually at http://mochi.test:8888) that most tests talk to. It's a constant pain point that running Robocop tests locally requires a network connection between the phone and the developer's box. And it's opaque how to run just the server in the background, etc, etc. One can't (easily) run chrome privileged scripts from the mochitest server. Bug 777451 introduced (or extended) the roboextender XPI to make it easier to push chrome content to the device. It's also easier to test roboextender things locally. Most of our tests just need a resource; they don't need an HTTP server to serve it. I'd like us to use robocop.apk's assets/ folder for such resources. This does have the downside that developing TestJavascript-derived tests is harder (since you need to push a fresh robocop.apk to get updated resources, rather than just editing the resources locally and serving fresh copies via HTTP). Since it's so hard to initiate the server and test locally, it ends up being less of a win than I had hoped for. I think that minimizing (or even getting rid!) of the ambient server, so that it's easier to run more of our tests locally, is worth sacrificing that dynamic test writing capability.

One note on this: we're currently using some non-trivial .sjs files. For background services, we've implemented such things in light weight (!) Java servers that we spin up on a separate thread as part of our test itself; it works fine. Not as nice as .sjs, but fine. This probably wants some test-only HTTP server code; we use org.simpleframework in background services.

Another note: there's no way to get a file:/// URL to an asset (something in assets/). WebView has special handling for Android assets and resources; see [1]. I think we might want to implement Gecko protocol handlers similar to android_asset and android_res for GeckoView, but this would be accessing an asset outside of Fennec, so it wouldn't apply. I think the simplest thing to do is to adapt getAbsoluteURL to either extract asset files to a temporary location that Fennec can access with a file URL, or to stand up a Java server that runs on a separate thread during tests and serves asset files over HTTP. So an on-device implementation of mochi.test:8888. [1] http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.4_r1/android/webkit/StreamLoader.java#StreamLoader.setupStreamAndSendStatus%28%29

Mass closing Firefox for Android :: Testing bugs with no progress in 2017. If this bug is important to you, please re-open.