uBlock Origin 1.1.1 broken in FF-nightly until I disable/enable

[oconnore]

Hi,

When I load Firefox Nightly, uBlock is not listed in the context menu, does not block ads, and shows up in my Add-Ons tab like:

If I hit disable, and then enable, it shows the proper menu items, and starts blocking ads.

[oconnore]

This also occurs with the most recent dev build for #640

[raidenii]

Similar problem on SeaMonkey 2.38, if chose not to launch browser at startup (e.g., only boot mail client), uBlock0 then requires a disable/enable to work. I'm currently using uBlock0 1.1.1.

[drbluetongue]

I can confirm this in Android FF nightlies with the latest dev version of uBlock O. I thought I was going crazy!

Has been happening for a week or so

[gorhill]

@AlexVallat, given this is a Firefox for Android issue, is it something you would be willing to look into? I am not very well equipped to debug for Android. I have access to one (it's not mine) but I can mostly just check whether things work fine or not, but it's not set up to investigate the source of issues.

[AlexVallat]

I've had a look at this - I can reproduce the issue, but unfortunately there's nothing in the error log, either through remote debugging or logcat. I tried doing a custom build with some extra diagnostic logging, but it appears that Nightly is currently unable to install .xpi files from the filesystem.

Nightly just seems unusable as a dev target at the moment. I'd suggest waiting to see if this hits beta, or at least aurora - with any luck they'll have fixed whatever has gone wrong with the addon loading system by then.

[drbluetongue]

https://bugzilla.mozilla.org/show_bug.cgi?id=1210476

Filed a bug.

[Hrxn]

What? Nightly?

You honestly expect things to work? 😉

[oconnore]

@AlexVallat just to clarify, this also happens with the official signed uBlock Origin from the marketplace. Also, at least one other add-on (self destructing cookies) works fine. (Everything you said could still be true, I'm not that familiar with Firefox add-ons)

[gorhill]

This was one month ago.. Is this still an issue with the latest FF Mobile Nightly?

[oconnore]

@gorhill unfortunately, yes. I just checked with today's build, and uBlock 1.3.2. It works fine in Firefox Beta, I haven't checked Aurora.

[AlexVallat]

OK, I found a workaround to get local XPI files installed on Nightly, so I could investigate a bit.

Turns out, the problem is that when the notification for domwindowopened is observed appShell.hiddenDOMWindow is now not yet available. So https://github.com/gorhill/uBlock/blob/master/platform/firefox/bootstrap.js#L110 fails and loading stops. It waits for another domwindowopened event indicating that the hidden window has now been created, but this never occurs.

Experimentally, if this check is ignored then by the time DOMContentLoaded fires for the window, appShell.hiddenDOMWindow is available, so onReady can use it. I don't know exactly at what point it becomes available, though, so I don't know how safe it is to remove the check and just assume that DOMContentLoaded on the first window to notify domwindowopened is.

[gorhill]

It waits for another domwindowopened event indicating that the hidden window has now been created, but this never occurs.

Thanks for this.

I have become wary of relying on specific cascade of events in FF in some cases (for example, gorhill/uMatrix#357), it takes only one event not firing as expected to break the whole sequence.

So given what you've found, I think I would prefer to rely on time-based events, i.e. poll the environment at regularly until it is as expected -- or give up after a set number of tries. This will work regardless of platform and no more worries about a specific sequence of events.

I am assuming nsITimer is available in bootstrap code.

[AlexVallat]

Yeah, given that there's no documentation on what point hiddenDOMWindow is available, and the most obvious way of waiting for domwindowopened to indicate that it has been created is no longer reliable, the best solution is probably just to check every few hundred ms until the thing shows up. Inelegant, but at least it will work and a sensible error message can be logged if it hasn't shown up after half a minute or so.

[drbluetongue]

Yeah this looks like its fixed, good job

[oconnore]

@drbluetongue @gorhill @AlexVallat It's not fixed for me. I am on 45.0a1 (2015-11-03). I first applied the github .xpi update on top of the existing uBlock. It worked until I forced Nightly out of memory and then restarted. Same issue. I then uninstalled uBlock, and re-installed from the .xpi build on github. Again, worked fine until I closed nightly and re-opened.

@AlexVallat @drbluetongue can you reproduce when forcing nightly out of memory after the install? If not, can you point me towards documentation on getting better diagnostics (at that point, it's likely something particular about my environment that's triggering the issue).

[gorhill]

@oconnore I just fixed another unexpected condition in a code review commit, latest build is in beta 2.

[oconnore]

@gorhill fixed now 👍 😄

[gorhill]

Nice. I will push this one on dev channel on AMO.