uBlock 1.12.00 + Stylish breaks session store on Firefox for Android Nightly

[buttercookie42]

STR:
0. Make sure tab restoring (Settings -> Advanced) is set to "Always restore"

1. Open a few tabs
2. Install/enable Stylish 2.0.7 and uBlock 1.12.0
3. Kill Firefox (Quit/Swipe away) and restart

Result:
The tabs from the last session open, but don't load and are completely broken - manually loading an URL in them doesn't work, either. Switching between these broken tabs gives errors like
GeckoConsole: [JavaScript Error: "TypeError: aTab is null" {file: "chrome://browser/content/browser.js" line: 1434}]

Notes:
The last unaffected uBlock version was 1.11.5rc1.
1.11.5rc3/4 were completely broken even without Stylish enabled (and slightly different errors in the startup log) and rc6 started the current behaviour, i.e. problems in combination with Stylish.
I've observed this with a recent Firefox for Android Nightly - a local build from today and the official 2017-03-27 Nightly. Since I don't see this issue on Release, I'm also going to investigate whether I can find out which Firefox change caused this difference in behaviour.

Logs:
uBlock 1.11.5rc3-4.txt
uBlock 1.11.5rc6.txt
These errors look like somehow somewhere browser window initialisation is broken.

Edit: Forgot to add - I've tested with all my other add-ons disabled.

[gorhill]

You should probably also report the issue on bugzilla.

[buttercookie42]

I've eventually figured something out - there's a race condition going on in Fennec on startup between the Gecko-side browser window starting up and being ready and events from the Java UI being dispatched to Gecko. In the case where things fail, the UI's events are sent to Gecko before the browser window is properly ready.

For me, things got worse (i.e. almost always reproducible) when testing with builds after bug 1344892 had landed, but I was seeing the occasional strange behaviour even before it.

So presumably Stylish is slowing Gecko startup down a little, uBlock does that as well (and for some reason 1.12.0 is probably a little bit slower than 1.11.4) and bug 1344892 is either slowing things down further as well, or else speeding up the message dispatching code path - the end result being that at least on my phone Java UI event dispatching now very frequently starts before the browser window is ready to handle them.

So I'm not sure how much there is that you can do (although it would be interesting to find out whether uBlock 1.12.0 is now really slower to start up on Android and whether there's any potential to speed it back up again), but in any case I've opened bug 1356563 for the race condition in Fennec.

[gorhill]

and for some reason 1.12.0 is probably a little bit slower than 1.11.4

I don't know whether it is slower, but the main change in 1.12.0 is that uBO is now hosted in a windowless browser rather than in a hidden frame, see:

• uBO broken on Firefox mozilla-central tip #2493
• Stoped working on 55.0a1 (2017-04-01) (64 bit) #2505
• Firefox issue uncovered as a result of the above change: https://bugzilla.mozilla.org/show_bug.cgi?id=1353022.

[buttercookie42]

A fix is in the process of landing on mozilla-central, so feel free to close this on your side, too.

[gorhill]

As mentioned above by @buttercookie42, this was the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1356563.