Skip to content

Loading…

[Safari] Clearing history and website data stops uBlock on restart #523

Closed
neilrooney opened this Issue · 15 comments

4 participants

@neilrooney

After clearing history and website data and restarting safari, uBlock simply stops working. It does not block ads or allow you to enter the uBlock preferences panel.

The only way to get it working again is to re-install the extension.

@neilrooney

Actually scrap that, simply restarting Safari stops uBlock from working.

@chrisaljoudi

@neilrooney do you get '?'s in place of the numbers in the popover?

@neilrooney

@chrisaljoudi I don't. I'm thinking it might be a cookie problem? Possibly the blocking of third party cookies is causing it?

@gorhill

What version of Safari is this by the way?

@neilrooney

@gorhill the latest version for Mac OS X 10.10.1

screen shot 2015-01-18 at 16 16 20

@gorhill

@chrisaljoudi I read the following in Safari Developer Library:

allocate database storage for your extension in the Extension Storage section of Extension Builder ... The default storage amount is none. You can choose a value from 1 to 100 megabytes.

What is the quota for uBlock?

The symptoms described in this issue evoke that of having problem reading the settings, it could be that uBlock's settings are truncated.

@Deathamns

@gorhill 50MiB should be enough. It can be increased, but I didn't see the point.

@gorhill

Yes 50MB is enough. I am at 3MB use with mirroring enabled. So there is something else tripping uBlock at load time, when loading settings by all appearances since the issue is not there with a fresh install, i.e. when no settings exist on disk.

@gorhill

I think hasOwnProperty() should be used when persisting object content:

https://github.com/gorhill/uBlock/blob/master/platform/safari/vapi-background.js#L128
https://github.com/gorhill/uBlock/blob/master/platform/firefox/vapi-background.js#L197

Throughout uBlock's code, I have been using storage.set() as per Chrome API doc:

Primitive values such as numbers will serialize as expected. Values with a typeof "object" and "function" will typically serialize to {}, with the exception of Array (serializes as expected), Date, and Regex (serialize using their String representation).

I can't tell without going thoroughly through the code whether there are cases where storage.set() is called with enumerable properties which should not persisted, but I can tell that if there is such case, that could explain the issue here.

@chrisaljoudi

@gorhill yep, 50MB right now.

The problem appears to be, as you said, the for..in loop not skipping irrelevant/BS keys. PR #537

@gorhill gorhill closed this in #537
@Deathamns

@gorhill How could that be the problem, if this is the first issue report about this?
I didn't see any place where you used other than plain objects (which properties are not enumerable and don't have inherited properties from prototypes).

@chrisaljoudi

@Deathamns older versions of Safari (which is to say WebKit/Nitro) demonstrate certain unwanted keys iterated over in for..in

@gorhill

@chrisaljoudi You want me to push a new revision for this change?

@chrisaljoudi

@gorhill there's a few more things I'd like to push (will have the PR in within 12 hours), and it'd be neat to have the changes in one release. However, it's up to you if you think we shouldn't wait.

@gorhill

@chrisaljoudi There is no serious bug going on, I just wanted to know if you wanted the changes up for Safari users. Your call whenever you feel a fix is a must-have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.