Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
oconnore opened this issue Sep 26, 2015 · 18 comments
Closed

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

oconnore opened this issue Sep 26, 2015 · 18 comments

Comments

@oconnore
Copy link

@oconnore oconnore commented Sep 26, 2015

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:

2015-09-26 19 47 43

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

@oconnore

This comment has been minimized.

Copy link
Author

@oconnore oconnore commented Sep 26, 2015

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

2015-09-26 20 00 56

@raidenii

This comment has been minimized.

Copy link

@raidenii raidenii commented Sep 27, 2015

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

This comment has been minimized.

Copy link

@drbluetongue drbluetongue commented Sep 30, 2015

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

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Oct 1, 2015

@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

This comment has been minimized.

Copy link
Contributor

@AlexVallat AlexVallat commented Oct 1, 2015

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

This comment has been minimized.

@Hrxn

This comment has been minimized.

Copy link

@Hrxn Hrxn commented Oct 1, 2015

What? Nightly?

You honestly expect things to work? 😉

@oconnore

This comment has been minimized.

Copy link
Author

@oconnore oconnore commented Oct 2, 2015

@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 comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Nov 3, 2015

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

@oconnore

This comment has been minimized.

Copy link
Author

@oconnore oconnore commented Nov 3, 2015

@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

This comment has been minimized.

Copy link
Contributor

@AlexVallat AlexVallat commented Nov 3, 2015

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

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Nov 3, 2015

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

This comment has been minimized.

Copy link
Contributor

@AlexVallat AlexVallat commented Nov 3, 2015

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.

@gorhill gorhill closed this in 6bec4d7 Nov 3, 2015
@drbluetongue

This comment has been minimized.

Copy link

@drbluetongue drbluetongue commented Nov 3, 2015

Yeah this looks like its fixed, good job

gorhill added a commit that referenced this issue Nov 3, 2015
@oconnore

This comment has been minimized.

Copy link
Author

@oconnore oconnore commented Nov 3, 2015

@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

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Nov 3, 2015

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

@oconnore

This comment has been minimized.

Copy link
Author

@oconnore oconnore commented Nov 3, 2015

@gorhill fixed now 👍 😄

@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Nov 3, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.