Loading…
Ads may show in pages opened when launching the browser #184
2 participants
The issue should have been already somewhat mitigated with the updating of only the used filter lists -- as opposed to all assets before 0.5.0.0. At this point figuring ways to improve load time will help, and optimizing such code is always welcomed. However I fear there is not much left to optimize significantly in there. Anyway, more digging needed.
From Crowdin:
when you launch browser and on home page there are ads didn't blocked. On "Privacy" i have two filters enabled. "Predict network actions to improve page load performance" enabled. I have this problem on www.onet.pl and here http://biznes.onet.pl/wideo/fabryka-porsche-w-lipsku-robi-wrazenie,153109,w.html or http://ekstraklasa.tv/ekstraklasa-wybierz-najladniejsza-bramke-6-kolejki-t-mobile-ekstraklasy/qffj0#play check this videos ublock don't block ads before this videos. On this site www.onet.pl almost before every videos ublock don't block ads, ABP blocks all. Hmm maybe if u want i can send you adblocklist what i use in ABP but i think it's the same.
Ok, I tried with one tab opened at http://biznes.onet.pl/wideo/fabryka-porsche-w-lipsku-robi-wrazenie,153109,w.html. Closed the browser (Chromium 64-bit on Linux), launched the browser, and the ad didn't show up in the video, and 35 net requests were reported as blocked. In doubt, I disabled uBlock and refreshed the page and the ad played. All my filter lists (many) load from the cache or locally because they are all deemed up to date. There could be a problem if one or more lists would need to be fetched remotely though.
In #108, it was suggested I should always load local at launch, then update later if necessary. That's an option, and I think it is what ABP does. This is still no guarantee ads will be blocked at launch, due to browser design. But it is mitigation.
http://www.linux.org.ru/ loads much faster, and always displays an ad at top after restart(opera, rus adlist, 5.0.1), no ad after reload.
always displays an ad at top after restart
Interesting, I tried with Google Chrome on Linux (I don't want to install the dev version of Opera, I'm trying to not clutter my main computer) and I can't see the ad (RU Ad enabled). I had to disable uBlock to find out how it looked.
One thing has changed in 0.5.1.0 with regard to load stuff, there is one less local file loaded at start up. But I find it hard to believe this could account for the difference.
Whether the difference is caused by Opera or the code change between 0.5.0.1 and 0.5.1.0, I don't know. Maybe it will still happen for you with 0.5.1.0, I suspect it's just that the page doesn't load as fast from my location.
Something is clear though, improving load time of filter lists is the way to go to mitigate the problem (it will never be really fixed, as per current browser design). The idea of making the filter engines streamable is more and more attractive, that would allow to skip all the reading/parsing/duplicate detection/etc of the filter lists.
opera uses (optional) feature similar to extension "lazy tabs", so only single tab is loaded on restart.
this may also happen due to another possible bug - "ublock filters" are marked as "may be obsolete", and autoupdate/update now doesn't clear this status.
edit - after disabling this list i was able to purge cache, and now it has normal status.
may be due to other extensions, i'll check this later
"ublock filters" are marked as "may be obsolete", and autoupdate/update now doesn't clear this status.
That's not normal. A new bug should be opened for this.
"ublock filters" marked as "may be obsolete" and autoupdate/update doesn't clear this status #186
So I finally did get the banner for http://www.linux.org.ru/, as there was a version change, which caused the cache to be flushed, which caused all the used 3rd-party filter lists to be re-fetch from remote servers, thus the delay was too much. Re-launching the browser again, the banner was filtered properly. So this just confirm it depends on how fast filter lists are loaded/parsed/etc.
Looks like the other idea of delaying updating, i.e. not updating at launch is getting more and more attractive.
just got an idea, i have 135ms network latency to github, that might be the reason for you not getting the ad.
I see. Yes this could be a problem, as https://raw.githubusercontent.com/gorhill/uBlock/master/assets/checksums.txt is downloaded unconditionally at launch, even if auto-update is disabled. I will have to think hard to streamline all bits which may contribute to delaying the loading/enforcing of filters.
Snapshot code is in:
- Without a snapshot available: 1,150 ms before all filters loaded (default lists).
- With a snapshot available: 240 ms.
Snapshot = dumping internal state of filtering engine so that it can be reloaded from snapshot, bypassing parsing etc. A snapshot will be created after filters have been loaded normally through parsing the first time. So this create an overhead when the snapshot has to be re-created (each time filter lists changes, or their content), but we gain multiple times the spent overhead when reloading the extension.
Snapshot code is one part of the solution. The other part is to avoid querying remote server(s) at launch time. This will be delayed to some time after launch is completed, to find out whether there are updates. Will work on this and then will find out how much more it helps.
What I call "snapshot" above, I refer to "selfie" from now on. The 240ms time reported above has been further cut to 170ms by also having publicSuffixList supports selfies.
Testing shows that this is fast enough to block ads on usual sites after restart.
Without selfie, they are at least hidden with cosmetic filters.
Thank you.
One last bit I can add to maybe completely fix the issue is to also take care of what should normally have been blocked net requests. Given that uBlock might be up and ready after a web page completely loads, any net requests which would have been blocked normally will appear on the page (typically banners, etc). I could however create a special script just for the purpose of going through all iframes, imgs, etc on the page to "post-evaluate" their URL, and remove any which is a hit on the net filters.
This is an issue brought forth regularly.
I will have to look more into this if this can be mitigated, as there is no way for an extension to stop the browser from opening tabs.
Even if I would block until ready the top
main_framerequests (which doesn't sound like a good idea in the first place), there is just no guarantee that even the net request handler will be up and running before tabs. Nowhere in chrome API doc is it stated that extensions execute before tabs.Related issues: #108, and many feedback entries in Chrome store.