After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 617944 - Adblock should not block full pages
Adblock should not block full pages
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 723262 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-06 18:08 UTC by Bastien Nocera
Modified: 2015-02-17 16:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2010-05-06 18:08:14 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.
Comment 2 Alessandro Biasi 2012-04-25 07:10:08 UTC
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
Comment 4 Carl van Tonder 2012-05-10 17:24:12 UTC
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.
Comment 5 Carl van Tonder 2012-12-16 03:10:25 UTC
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
Comment 6 Bastien Nocera 2012-12-17 16:45:02 UTC
Works for me as well with:
epiphany-extensions-3.6.0-1.fc18.x86_64
epiphany-3.6.1-2.fc18.x86_64
Comment 7 Carl van Tonder 2012-12-20 20:39:15 UTC
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...)
Comment 8 Carl van Tonder 2012-12-20 20:42:23 UTC
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.
Comment 9 Bastien Nocera 2012-12-20 21:09:03 UTC
Yep, still a problem indeed. Had the problem this afternoon going to http://imageshack.us , a dump for screenshots.
Comment 10 André Klapper 2013-05-27 16:12:07 UTC
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.
Comment 11 Bastien Nocera 2013-05-28 09:28:12 UTC
Still a problem in the builtin AdBlock support.
Comment 12 Michael Catanzaro 2014-01-30 01:00:12 UTC
*** Bug 723262 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2014-03-22 15:05:58 UTC
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?
Comment 14 Michael Catanzaro 2014-03-22 19:03:45 UTC
(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).
Comment 15 Michael Catanzaro 2014-03-23 17:11:01 UTC
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.
Comment 16 Michael Knepher 2014-03-28 20:45:41 UTC
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?
Comment 17 Michael Catanzaro 2014-03-28 23:04:14 UTC
Yes
Comment 18 Michael Catanzaro 2015-02-17 16:53:37 UTC
This was fixed in 3.10, and on the 3.8 branch after the last 3.8 release.