Loading…
with v0.4 uBlock fails to collapse the elements some times.. #156
3 participants
issue can be reproduced on fudzilla.com too, here in this case it does happen on subsequent reload..
reproduced with fudzilla.com 
Sorry about this, I had removed code which I forgot was useful 
thanks gorhill for fixing this! It is much better now.
However, a little different than the original issue here..On the below site, blocked element can be briefly seen for 3-4 seconds before it is hidden. Not a big deal, just wanted to report it :)
http://happystreams.net/vhgll4geabm4
On ABP, the same is seen for half a second or less..
And let me know if you would want to track this as an issue, i will open a new bug..
blocked element can be briefly seen for 3-4 seconds
Hmm.. It was a fraction of second in my case -- less time than it takes to blink an eye (and only the first time since afterward the CSS rule is in the cache). Can you reproduce systematically that 3-4 second delay?
in my case in first time 2 seconds to hide....
Going to try and find out what could cause the delay. Meanwhile.. Any other extensions installed? (I use only uBlock when I test)
Only uBlock in my case...
(and only happens in the first time)
What filter lists are selected?
it happens only on first. please try with incognito mode...it will make sure everything is cleared ;)
in my case i am able to reproduce every time upto 3 seconds sometimes 4 seconds. Please see the attached screenshots for timestamp which shows for 2 second gap..
can reproduce with uBlock with and without HTTPSB..
For filter list see below, also fanboy india is selected...
Oh ok, you meant http://happystreams.net/dl, not http://happystreams.net/vhgll4geabm4?
ohh..I mean http://happystreams.net/vhgll4geabm4 only. You need to click proceed to video button ...
i believe thats a post request, will not see the url there...
Yes, there is a form. Anyway, I was testing the page with the button, not the one with the video.
ok. i should have posted the screenshots originally..sorry for the confusion..
anonymous frames? see
https://issues.adblockplus.org/ticket/581
no frames...confirmed thru httpsb.
its a div..
That the condition for such a delay to happen with uBlock: The page was never visited before, thus nothing in browser's cache, and nothing in uBlock's cache.
If the page had been visited before, uBlock's behavior will resemble ABP. If the page had been visited before with uBlock's cache filled, behavior is better than ABP (likely you won't even see the frame at all).
So the one case where uBlock is worst than ABP is certainly due to the fact that the filtering of such embedded frame is taken care by the content script injected at document_end time -- not something new to 0.4, behavior was same with previous version.
One solution I can think of is to duplicate the blocked content hiding code into contentscript_start.js (currently code is only in contentscript_end.js). The consequence though is that the code in contentscript_start.js would be forced to stay in memory (because event listeners) -- while it is currently flushed from memory. So is it really worth to increase uBlock's memory footprint for a one single time delay which in all likelihood won't be seen afterward unless the browser cache is cleared and uBlock's cache is cleared?
Just to add to the above: given how edgy is the "annoyance", and given that as a developer my responsibility is to balance one inconvenience against the gain/loss of benefits to all users, and given that the solution to this one annoyance would lead to increased memory footprint for all users, including those who do not care about sites where the "annoyance" occur, and including users who picked uBlock because of its friendliness toward system resource, I do not see fixing such edgy cases as a gain for the majority of users.
I agree 100% with you.
Definitely not the worth of fixing it at the cost of memory/cpu. Since this is more of an small annoyance thing.
Thanks for the explanation!
-Harsha
In any case, I keep the door for a fix opened, I may want to experiment stuff in the future which could fix this, but ultimately the vim stress test is the one which will decide whether or not a fix is worth it: if the test shows no change in memory footprint, fix will make it, if it shows significant increase, fix won't make it. The vim test is extreme, but it is excellent at showing in which direction uBlock is moving regarding memory efficiency.
For the record, with v 0.4.0.1, the memory footprint of the vim test page stands under 530-540MB after forcing garbage collection (Chromium 64-bit).
thanks raymond!
out of curiosity, i did a crude and quick VIM test and here are my results - Isn't load times not higher when compared to just plain browser (no addon), is this expected?
(new incognito window for each addon)
Chrome 32 bit - with ABP - 431 Requests | 1.6 MB transferred | 32.78 s (load: 1.4 min, DOM: 7.16 s) - 1224700k
Chrome 32 bit - with uBlock - 430 Requests | 1.6 MB transferred | 17.51 s (load: 1.0 min, DOM: 6.51 s) - 610932k
Chrome 32 bit - no addon - 431 Requests | 1.6 MB transferred | 20.76 s (load: 20.79 s, DOM: 6.25 s) - 190052k
Garbage collection need to be forced to be sure we measure proper memory footprint, from the numbers you collected I can tell it didn't happen. I personally force garbage collection using dev console / Timeline / Trash icon / click three times (with a delay between each click), then I close dev console (which influence web page mem footprint itself) and wait around 1 minute. Then the mem figures are more better reflecting reality and can be more meaningfully compared.
For the timing, care needs to be taken to ensure all tests benefit from the data being in the browser cache.
The one less request of uBlock is because it blocks google-analytics.com more thoroughly than ABP.
Yes, i did not force the garbage collection for those 3 tests ( will test with gc later). I am more interested to know what might be the reason in load time difference... 20.70 s Vs 1 min...is this expected?
Not unexpected.
For uBlock, two content scripts are injected in every page and in every frame.
For ABP, I can see four content scripts injected in every page and in every frame as per manifest.json file.
It looks like element hider code is injected in ABP all the time, while in uBlock the element picker code is injected only when the feature is used, and only in the top frame. Probably ABP would gain by injecting that code manually only when needed.
Expected: All blocked elements should be collapsed.
Actual: Blocked elements are not collapsed as shown in the attached screenshots..
Note:
1. This only happens on the first load with above mentioned procedure. Does not happen if the tab is reloaded. Elements collapse properly.
2. Can be reproduced with or without HTTPSB. Please see screenshots.
3. System: W8.1, Chrome v36.