Cosmetic blocking in Safari pinned tabs

[PCheezo]

Describe the issue

Ublock eventually breaks and wont block ads using Safari Favorites Tabs.

Steps for anyone to reproduce the issue

1. pick a site i.e. YouTube:
2. Make it a favorite tab
3. after a while uBlock will eventually stop blocking ads on YouTube.
4. If you already have a favorite tab setup and then activate uBlock it will not fully work unless you remove the favorite tab and re-activate uBlock on it.

Your settings

http://mysticalos.com/images/randomcompthings/ublock_settings.jpg

• Safari version: Version 10.0.2 (11602.3.12.0.1)
• uBlock Origin version: 1.10.0 from latest source
• MacOS version: 10.11.6 (15G1108)

Your filter lists

http://mysticalos.com/images/randomcompthings/ublock_lists.jpg

[Freida-Moo-Goo-Gai-Pan]

Try disabling "Preload Top Hit in background" under preferences--- Security.

[PCheezo]

this seems to have worked. what i had to do though, was to unpin the favorite tab, close it, open a new one to replace it, and then it worked.

[PCheezo]

actually nvm. anytime i restart safari ublock will quit qorking in a favorites tab.

[el1t]

I believe you were referencing the pinned tabs feature, not the favorites bar/new tab page. As far as I can tell, the requests are still being blocked, but cosmetic filters are not being applied. To reproduce:

1. Pin a tab (e.g. https://youtube.com)
2. With pinned tab any tab (e.g. youtube) selected, quit Safari
3. Reopen Safari, and cosmetic filters will not work until page is manually refreshed

edit: seems to occur on any tab, not just pinned tab

[el1t]

Upon further inspection, it appears that when Safari is restarted, contentscript.js asks for cosmetic filters before the cosmetic filtering engine is ready. The content script will abort, and no cosmetic filtering will occur. This is the same issue as gorhill/uBlock#197. Some approaches to fixing this:

• The client could wait to send the message (delays every page, could still fail)
• The client could ask again after a small delay (potential to fail again)
• The engine could delay its response until it is ready
• The background page could send a second response once the engine is ready

Currently, there is no attempt to retry or wait for readiness. However, the engine is expected to be ready eventually. Thus, the client should never fully abort (unless the engine fails). It also doesn't make sense for an unready engine to retrieve selectors when all results get ignored by the client. This should probably be an upstream fix, but it is nontrivial.

[darrenmhill]

Also seeing this issue with pinned tabs. Annoying as I have many! Any progress on this? It's an issue with the latest Safari version 11.0 (High Sierra latest beta).