641291 - Omnibus ad-blocking bug for March 2011

Status: RESOLVED FIXED

(Camino Graveyard :: Annoyance Blocking, defect)

Comment 1

[philippe (part-time)]

lots of ads on sourceforge japan
http://sourceforge.jp/projects/mplus-fonts/

div#ad-leaderboard > div#ad-superbanner (top)
div.ad300 (rh sidebar)
all have: 
<a target="_blank" href="http://cou.adjust-net.jp/click/pegasus?
<img src="http://cre.adjust-net.jp/

currently blocking on div[id="ad-leaderboard"], div[class="ad300"]

(there are some goooogle ads low in the page - those don't want to play nice)

Comment 2

[Chris Lawson (gone)]

Seeming false-positive on

http://www.duesseldorf.de/stadtbuechereien/service/webopac.shtml

The search section (at the top of the center column of content) appears and disappears in a recent nightly based on whether I have "Block Web Advertising" unchecked or not.

cl

Comment 3

[philippe (part-time)]

(In reply to comment #2)
> Seeming false-positive on
> 
> http://www.duesseldorf.de/stadtbuechereien/service/webopac.shtml

the search form is in an iframe, deeper inside that iframe, the form fields are wrapped in div[class="nur_anzeige"]
which is blocked by div[class$="anzeige"] /* line 694 */.

Comment 4

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

(In reply to comment #3)
> wrapped in div[class="nur_anzeige"]
> which is blocked by div[class$="anzeige"] /* line 694 */.

Which is the German word for "ad", so I don't think the rule is unreasonable (added for bug 503745, ads on Heise.de).  (Also, the rule's been in since July 2009 with no problems.)

Comment 5

[Chris Lawson (gone)]

Yeah, I was hoping someone might be able to explain why that site seems to feel it's necessary to put a search form inside a div called "ads".

Comment 6

[philippe (part-time)]

(In reply to comment #4)
> (In reply to comment #3)
> > wrapped in div[class="nur_anzeige"]
> > which is blocked by div[class$="anzeige"] /* line 694 */.
> 
> Which is the German word for "ad", so I don't think the rule is unreasonable
> (added for bug 503745, ads on Heise.de).  (Also, the rule's been in since July
> 2009 with no problems.)

well, according to my BeoLingus German-English dictionary

advertisement; ad [Am.]; advert [Br.]
but also: indexing, indication, notification, prompt, readout
display

the online version:
http://dict.tu-chemnitz.de/dings.cgi?lang=en&service=deen&opterrors=0&optpro=0&query=anzeige&iservice=&comment=&email=

Comment 7

[philippe (part-time)]

http://www.apple.com/ipad/
click the 'Watch the new TV ad' button (right, under main image)

AR: nothing happens…
The movie is wrapped in a div with ID="MASKED-ad"

blocked by div[id$="-ad"], /* line 540 */
fix: add div[id$="-ad"] {display: block !important} to the FruitCo override block. We already have div[id="ad"].

And blame DaringFireball.

PS - there should be whitespace between display: & block on that line.

Comment 8

[philippe (part-time)]

Attachment: generated source for ipad ad movie

(see comment 7)

Comment 9

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

(In reply to comment #1)
> (there are some goooogle ads low in the page - those don't want to play nice)

div[id="google_flash_inline_div"] and div[id="google_flash_div"] block the ones I was served (but I also wasn't served unblocked ads for the leaderboard and right-side blocks, so IP-differences/ad-rotators at work ;) ).

Comment 10

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

Attachment: March Omnibus ad-blocking

I had a couple of minutes this afternoon, so I whipped up this patch to keep us on track here ;)

If bug 632261 were in, I might have made the argument that for 2.1, the Düsseldorf library thing should be handled at the user level, but 1) that patch is not yet in and 2) although the usage seems bad, the site seems important-enough that we fix it ourselves.

As I mentioned in comment 4, that German "ad" rule has been in since July 2009 without any prior reported problems, so I'd rather not remove it based on this alone.  We should, however, keep an eye out for other problems and tweak the rule if we find some.

Comment 11

[Stuart Morgan]

Comment on attachment 524081 [details] [diff] [review]
March Omnibus ad-blocking

sr=smorgan

Comment 12

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

http://hg.mozilla.org/camino/rev/2209f9d21748

Comment 13

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

I landed these two on the CAMINO_2_0_BRANCH and moved the tag for 2.0.8 to include them, since they've been well-tested by now and they were therefore simple, low-risk fixes from the forgotten-in-the-mayhem "camino-2.0.8?" group.