
Loading…
Element hiding not works when navigating tab history (for iframes?) #202
I can reproduce.
There is a random component in the URL of the iframe. However I still do not understand why that doesn't work.
Upon back button, browser reports these are blocked:
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=1&ad=306
220&bt=22&bn=306220&rnd=915391383&tail256=unknown
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=155288&b
n=1&target=blank&bt=22&pz=1&rnd=153234673&tail256=
unknown
uBlock reports these are blocked (this matches above):
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=1&ad=306
220&bt=22&bn=306220&rnd=915391383&tail256=unknown
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=155288&b
n=1&target=blank&bt=22&pz=1&rnd=153234673&tail256=
unknown
uBlock's content script reports this loaded (does not match above):
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=155288&b
n=1&target=blank&bt=22&pz=1&rnd=36764676&tail256=
unknown
querySelectorAll'ing the page for iframe reports (does not match above):
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=1&ad=306
220&bt=22&bn=306220&rnd=162537982&tail256=unknown
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=155288&b
n=1&target=blank&bt=22&pz=1&rnd=36764676&tail256=
unknown
So the URL of iframes in the DOM does not match the blocked URLs. I don't know how this can happen, i.e. changing the URL of an iframe in the DOM without a load/error event being triggered. Need to investigate more.
Also, curiously I can't reproduce on my Chromium 34, but easily reproducible on Google Chrome 37.
Also, meanwhile, or for good since this also get rid of the quick appearance/disappearance of the iframe (which also happens with ABP), this filter fixes the problem:
russianfood.com##iframe[src^="http://ad.adriver.ru/"]
It's really weird. When using the back button, with Chromium 34, what is blocked and what is in the DOM is consistent, thus it work flawlessly. With Google Chrome 37, there are mismatches.
Now the hiding of the element works with ABP, but I suspect it might be because the way blocked requests are checked in the DOM, i.e. it could be because ABP evaluates fully the URL to check, whereas uBlock remember the requests which were blocked and just look-up these.
It is as if there is a bug in Google Chrome 37 (and probably Chromium 37), where a new URL is set for the iframe, and the resulting net request does not go through webRequest.onBeforeRequest API. Or the src property is changed without causing a request to be fired.
Yeah, there are a lot of issues for "iframe url" in chromium tracker that could affect this.
You can close this bug, if you think it's chrome bug.
You can close this bug, if you think it's chrome bug
I do think there is something wrong with the browser, but by the look of it the back button is a thorny issue to deal with, so whatever changed may have fixed some scenarios, but it broke uBlock scenario.
In any case, from the user's point of view it doesn't matter where the problem lies, they just expect uBlock to do its job regardless of where the fault is. I am currently thinking about the best fix. I want to keep the efficient look-up, but I need a fallback for the current scenario.
For the record re "I want to keep the efficient look-up":
It still is an efficient look-up, except that now, if the looked-up URL is not found in the internal request log, the URL will be fully evaluated against the filters.
This addresses the problem here of a script-generated URL with a random part in it. This in turn allowed me to implement a flushable request log, which brings much smarter memory usage in uBlock with regard to request log.
The internal request log for blocked requests and the request log for user purpose have been unified into one single request log.
Hiding works when clicking links, not works after back/forward browser buttons.
This reproduces the bug for me:
navigate to http://www.russianfood.com/recipes/bytype/?fid=1179
in same tab navigate to http://www.russianfood.com/recipes/recipe.php?rid=124711
click back/forward buttons.
You should see several uncollapsed blocks.
Seems to work for regular ads on other sites, but not for this one(iframes related?)
ru adlist, 5.1.0, opera.