[Safari] Manually updating filters fails

[exiva]

When updating the 3rd party filters manually, they never seem to update. Clicking Update Now causes the content of the page to go grey, and the blue beachball cursor to appear. The filters never update.

OS: 10.10.2 (14C99d)
Safari: 8.0.3 (10600.3.17)
uBlock 0.8.5.4

[gorhill]

There is a time out if some remote server(s) do not respond. How long did you wait?

[exiva]

Just did it and timed 5 minutes. No update, or error.

[gorhill]

Ok my bad, I should have mentioned the time out is somewhere between 15-30s. So there is definitely a problem.

[chrisaljoudi]

@exiva what filters do you have enabled?

[exiva]

[gorhill]

If it never times out, I suspect a javascript exception is occurring in the background page, causing the code to abort and as a consequence the dashboard is never notified. So looking at the console of the background should provide come clues.

[exiva]

I'm seeing nothing in the console at all.

[gorhill]

I know nothing about Safari. It has to be the background page. Is it where you looked? Usually developer mode is required etc. @chrisaljoudi could confirm where to look exactly.

[chrisaljoudi]

@gorhill @exiva probably in the background page console, yes. I don't know of an obvious way to inspect the background page of a packed extension in Safari (vs. using Extension Builder on source where there's an "inspect background" button).

I'll look at this as soon as I get home, though.

[chrisaljoudi]

@exiva I've been unable to reproduce here. Does this still occur with the just-released 0.8.5.5?

[exiva]

@chrisaljoudi Updating did nothing, uninstalling the plugin and reinstalling seems to have fixed it.

[chrisaljoudi]

@exiva oh. :( Sorry to hear that. I'll attempt to reproduce by clearing cookies/etc.

[exiva]

I backed up my settings. Maybe something in there will assist, I haven't tried with them imported again. https://gist.github.com/exiva/6909e6961c832fbc56ee

[chrisaljoudi]

@exiva I was able to reproduce by running the WebKit nightly alongside Safari. Do you have that running? The WebKit nightlies have weird "sharing" of stuff with Safari (cookies are shared, but not history — extensions seem to share execution space at some level).

If you are running WebKit nightlies alongside the stable Safari, I'd avoid keeping µBlock enabled in both.

This isn't something µBlock has control over, and working around it would reduce efficiency on common setups.

If you're not running WebKit nightly/something else screwing with Safari, then I'm curious to know whether 0.8.5.4 was your first version of µBlock to install.

[exiva]

No, I don't have any webkit nightlies. And yes, I had the extension from the old Safari thread installed (I forget what version it was) and installed the new one, then removed the old one.

[chrisaljoudi]

@exiva got it; that's the issue. I don't know if there is a way to have µBlock get rid of the traces of the old version when a new one is installed. @gorhill ideas? The problem is that vAPI.tabs is getting 'remembered' across the versions (if they're simultaneously installed) and that screws things up (one "instance" tries to access tabs that no longer "exist").

[chrisaljoudi]

The good news, if there are any, is that this won't be an issue starting at version 0.8.5.4 now that updates are not "manual" (no need to reinstall).

[gorhill]

@chrisaljoudi: @Deathamns wrote the safari port. I know nothing about Safari or OSX.

[chrisaljoudi]

@gorhill yep; was simply curious whether µBlock made any specific assumptions about the state-tracking and whether you had any specific ideas to decouple that state tracking from the global space (because I'd be happy to implement those if you do).

[gorhill]

@chrisaljoudi It's all dynamic. uBlock will look at which tabs are opened at start, and once shutdown nothing is remembered, aside user settings.