485865 - Omnibus ad-blocking bug for April/May/June 2009

Status: RESOLVED FIXED

(Camino Graveyard :: Annoyance Blocking, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

"Let there be no more ads, or flashing images…"

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Amazingly, we do not yet block div[id="ads"] (e.g. Digg's sponsored links, http://digg.com/search?s=diggbar+%2Bb )

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Revenge of the ELNK webmail ads: the ad image is coming from http://optimized-by.rubiconproject.com this month.

Given that the ad-servers keep changing, maybe we do just want to block the various ad iframes (bug 472010 comment 8 and iframe[name*="topskybannerframe"])?

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

On /., e.g. http://news.slashdot.org/comments.pl?sid=1219425&cid=27794609

<div class="ad1 advertisement"> contains the fabulous IE8 ad.

I think we had problems with the ~ selector before, which is kind of annoying.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

philippe, will you have time to look at this (particularly the "advert" regressions) in the next week or so?  I likely won't, and I'd rather not have this become Apr/May/Jun….

Comment 5

[philippe (part-time)]

For bug 491336 : a:link[href*="advert"] img was added to block ads coming from advert.leo.org

This could be changed to
a:link[href*="advert."] img
or even (safer)
a:link[href^="http://advert."] img

For bug 490292 : div[class^="advert"] is a tricky one
AdblockPlus has the following closely related rules:
*[class^="advert-"]
*[class^="adverts-"]

*[class~="advert"]

And also:
*[class^="advertContainer"]
*[class^="advertRight"]
*[class^="advertise-horz"]
*[class^="advertisement"]
*[class^="advertisment"]

None of those duplicate what is currently covered by Camino's rules.
I'm not clear why bug 437919 added that div[class^="advert"] rule; none of the pages listed there contains classes with that string; it makes it harder to test or regressions. The first two (as div[class^="...) would certainly be safer than what we have now.

(that is extracted from http://easylist.adblockplus.org/easylist.txt)

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> None of those duplicate what is currently covered by Camino's rules.
> I'm not clear why bug 437919 added that div[class^="advert"] rule; none of the
> pages listed there contains classes with that string; it makes it harder to
> test or regressions. The first two (as div[class^="...) would certainly be
> safer than what we have now.

According to my notes, it was used on herald-dispatch.com, but as you note, following the links from that bug, it's not currently used.  I think for the moment I'll just remove that rule, and we'll revisit it when we run into something that's not blocked.

Also, on http://abcnews.go.com/Technology/AheadoftheCurve/story?id=7460220&page=1 
div[id="bannerad"]

I'm going to wait a day or so to hear back from Mehmet in bug 499829 before posting a patch.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Apr-May-Jun 2009 Omnibus blocking rules

Fixes the items mentioned here, and fixes or ameliorates all the associated bugs.  At least half of the rules come from philippe this time around, so the quality as a whole should be better than usual ;-)

Comment 8

[Stuart Morgan]

Comment on attachment 386932 [details] [diff] [review]
Apr-May-Jun 2009 Omnibus blocking rules

sr=smorgan. Ship it!

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Shipped!

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Fixed for 1.6.9 by the rollup patch on bug 502536.