Plain mochitests run okay in TestRunnerActivity, but mochitest-chrome tests do not: They fail to start, resulting in no-output time-outs. (In contrast, mochitest-chrome runs okay in Firefox for Android.) You can kind-of see the failure in https://treeherder.mozilla.org/#/jobs?repo=try&revision=baec19c2360a2d44269463317f9cd44564ee2a58 but because there are so many time-outs, the task runs out of time and a lot of useful diagnostics are lost. The same issue can be seen in a local run with a command like: ./mach mochitest --flavor=chrome --app=org.mozilla.geckoview.test mobile/android/tests/browser/chrome In this case, TestRunnerActivity starts and loads the mochitest redirect.html, but runs no tests. The page displays "redirecting...", from redirect.html. Debugging with dump() shows that the custom event is being dispatched at https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/testing/mochitest/redirect.html#16 every 5 seconds. However, it seems the listener is not registered, since browser-test.js has not loaded. https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/testing/mochitest/browser-test.js#103

This here looks relevant: https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/testing/mochitest/api.js#12-16,28-39 ... and the check for specifically Fennec's browser.xul isn't just a formality, since a lot of (most?, all?) mochitest-chrome tests are written with Fennec's browser.js API in mind.

and also the check for a "navigator:browser" window right below: https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/testing/mochitest/api.js#51

Thanks Jan. Yes, that explains it.