GNOME Bugzilla – Bug 617944
Adblock should not block full pages
Last modified: 2015-02-17 16:53:37 UTC
For example, adblock, with the default rules, will completely block this page: http://rss.slashdot.org/~r/slashdot/eqWf/~3/_Iif2_uWCOI/iPad-Is-Destroying-Netbook-Sales It looks like a bug, because the link will take you to a blank page with no URL in the location bar.
I could not load this page either: http://www.phoenixnewtimes.com/2010-05-13/news/cracking-life-lock-even-after-a-12-million-penalty-for-deceptive-advertising-the-tempe-company-can-t-be-honest-about-its-identity-theft-protection-service/
The same for all google feedproxy links http://feedproxy.google.com/~r/blogspot/MKuf/~3/xMTPohvy2sw/introducing-google-drive-yes-really.html http://feedproxy.google.com/~r/stormy_planetgnome/~3/QDDadysckTo/getting-management-feedback-from-your-kids.html epiphany 3.4.1-1 epiphany-extensions 3.4.0-1 libwebkit3 1.8.1-1
http://www.mixcloud.com/DJJFB/jfb-gettofunk-partybreaks-mix/?utm_source=widget&utm_medium=web&utm_campaign=base_links&utm_term=resource_link This URL is blocked, but only with the query parameters — i.e., the following is fine http://www.mixcloud.com/DJJFB/jfb-gettofunk-partybreaks-mix/
Sorry, should have specified versions. carl@chaffinch:~$ rpm -qa | grep epiphany epiphany-extensions-3.4.0-1.fc17.x86_64 epiphany-3.4.1-2.fc17.x86_64 Tried clearing out ~/.gnome2/epiphany/extensions/data/adblock/* to no avail.
AdBlock no longer blocks any of the above URLs for me (all above pages load successfully). carl@chaffinch:[/media/data/Incoming]$ rpm -qa | grep epiphany epiphany-3.4.3-1.fc17.x86_64 epiphany-extensions-3.4.0-1.fc17.x86_64
Works for me as well with: epiphany-extensions-3.6.0-1.fc18.x86_64 epiphany-3.6.1-2.fc18.x86_64
Oh dear, spoke too soon. Here's another page that is completely blocked: http://www.google.com/imgres?hl=en&safe=off&tbo=d&biw=959&bih=915&tbs=imgo:1&tbm=isch&tbnid=Esx3xBgSZqsasM:&imgrefurl=http://www.etsy.com/listing/114379545/black-and-brown-deer-iphone-4-case&docid=6Snn2tDX7NUz8M&imgurl=http://img2.etsystatic.com/008/0/5755013/il_fullxfull.393040054_482w.jpg&w=600&h=480&ei=6XbTUPbWOpKN0QG47IHADQ&zoom=1&iact=hc&vpx=4&vpy=159&dur=869&hovh=201&hovw=251&tx=107&ty=221&sig=107672036608837496383&page=1&tbnh=143&tbnw=193&start=0&ndsp=30&ved=1t:429,r:0,s:0,i:92 This works with any Google images result link pointing to Etsy.com; I searched for "black and brown deer iphone case" as that is a product on the front page of etsy.com (I do not own an iPhone or want a case for one featuring a deer...)
It seems this bug can't be replicated just by visiting that URL (weird), but can with the following steps: 0. Enable AdBlock 1. Navigate to http://www.google.com/imghp 2. Search for "black and brown deer iphone case" with or without quotation marks 3. Click the first result Expected result: Above-linked page loads. Actual result: White (blank) page.
Yep, still a problem indeed. Had the problem this afternoon going to http://imageshack.us , a dump for screenshots.
According to its developer, epiphany-extensions is not under active development anymore. (For reference: https://mail.gnome.org/archives/gnome-i18n/2013-May/msg00035.html and bug 700924.) It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.
Still a problem in the builtin AdBlock support.
*** Bug 723262 has been marked as a duplicate of this bug. ***
Bug 726883 has a patch to show when something is blocked. My guess is that the: return uri_tester_test_uri (extension->priv->uri_tester, request_uri, page_uri, AD_URI_CHECK_TYPE_OTHER); call is too generic, and ends up blocking things that are images, css, etc. which wouldn't get blocked if they were of the correct AD_URI_CHECK_* type. Do we have a way to tag those properly?
(In reply to comment #13) > Bug 726883 has a patch to show when something is blocked. > > My guess is that the: > return uri_tester_test_uri (extension->priv->uri_tester, request_uri, page_uri, > AD_URI_CHECK_TYPE_OTHER); > call is too generic, and ends up blocking things that are images, css, etc. > which wouldn't get blocked if they were of the correct AD_URI_CHECK_* type. Looks like it requires implementation on both sides: uri_tester_test_uri() doesn't do anything with the type (besides to verify it's not AD_URI_CHECK_TYPE_DOCUMENT, which is never passed to it).
Really the biggest problem is that uri-tester.c only partially implements the spec: https://adblockplus.org/en/filters Some notes: * uri_tester_parse_line() is not fully implemented. In particular, whitelisting is not implemented, so we block much more than EasyList intends (probably including full websites). * uri_tester_fixup_regexp() is not fully implemented. Warning: I think the FIXME comment might be wrong. * uri_tester_parse_file_at_url() cuts off filters at 1999 characters, but EasyList includes much larger filters. (I have one almost 9500 characters long.) It looks like it will treat the next 1999 characters of the same filter as if it were a separate filter, and so on. (Probably only a minor problem.) Also, web_page_send_request() in ephy-web-extension.c supposedly never even tests the URL if it's the full page (see the comment "Always load the main resource"). That may be broken.
I've found some pages like io9.com for which epiphany won't load css files, etc., if ad blocking is on. Is this due to the same issue?
Yes
This was fixed in 3.10, and on the 3.8 branch after the last 3.8 release.