We are hiding a few more placeholders now: https://hg.adblockplus.org/adblockplusc ... 533195991e
Marking this as Fixed again.
[Fixed] 1.3.0.865 doesn't hide placeholders
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
One use reported he is still getting this message on http://www.bonimail.de/link/?15194bd3b5 ... 400d53a31b for example. The ad frame is blocked by "|http://$subdocument,third-party,domain=bonimail.de" in EasyList Germany. I also get this message there.TheIrreverend wrote:Is this is the same issue which is causing this in Google Reader - http://i.imgur.com/k9J0b.png? Frame Info - http://i.imgur.com/qMs5k.png
Re: 1.3.0.865 doesn't hide placeholders
I loved the old way......which gave all sorts of default placeholders to various request types.
Are there plans to once again replace blocked frames with about:blank, blocked images with a 1x1-pixel PNG, etc, even while the hidePlaceholders option is gone?
Also, was it the repeated retrieval of the hidePlaceholders option that was causing such poor performance, or was it the cascade of if/else statements?
Finally, will any of these "blank media" data: URIs find any use in this new blocking setup: forum/viewtopic.php?p=56465#p56465
I'm thinking about updating my so-far one-off "experimental swap-out build" just for the purpose of testing the effect of leaving that cascade of if/else statements (in fact, a bigger cascade) in.
Code: Select all
var collapse = filter.collapse;
if (collapse == null)
collapse = (localStorage["hidePlaceholders"] != "false");
if (collapse && type == "SUBDOCUMENT")
return {redirectUrl: "about:blank"};
else if (collapse && type == "IMAGE")
return {redirectUrl: "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAACklEQVR4nGMAAQAABQABDQottAAAAABJRU5ErkJggg=="};
else
return {cancel: true};
Are there plans to once again replace blocked frames with about:blank, blocked images with a 1x1-pixel PNG, etc, even while the hidePlaceholders option is gone?
Also, was it the repeated retrieval of the hidePlaceholders option that was causing such poor performance, or was it the cascade of if/else statements?
Finally, will any of these "blank media" data: URIs find any use in this new blocking setup: forum/viewtopic.php?p=56465#p56465
I'm thinking about updating my so-far one-off "experimental swap-out build" just for the purpose of testing the effect of leaving that cascade of if/else statements (in fact, a bigger cascade) in.
There's a buzzin' in my brain I really can't explain; I think about it before they make me go to bed.
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
Seconding what lewisje said. As it is now, hiding is too slow, and the broken images/frames are rendered before they can be removed, which causes lots of annoying flickering.
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
It is still happening for me (version 1.3.4.919) on that page and also on http://www.irfanview.de/MonztA wrote:One use reported he is still getting this message on http://www.bonimail.de/link/?15194bd3b5 ... 400d53a31b for example. The ad frame is blocked by "|http://$subdocument,third-party,domain=bonimail.de" in EasyList Germany. I also get this message there.
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
bonimail.de and irfanview.de both use frames (<frame>, not <iframe>). I've added collapsing for those as well, fix is under review: http://codereview.adblockplus.org/9756009/
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
Fix pushed: https://hg.adblockplus.org/adblockplusc ... 6dda1e1dca. There will be a new development build in a few minutes, it should be able to hide these frames as well now.
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
Still an error message on http://gf.wiretarget.com/dirt_3.htm with ABP 1.4.0.926.
Re: [Fixed] 1.3.0.865 doesn't hide placeholders
Also appears if you click on the link "Quelle: Facebook Werbeanzeigen" at the bottom on http://www.allfacebook.de/userdata/?period=1year.