Closed Bug 687017 Opened 13 years ago Closed 12 years ago

Omnibus ad-blocking bug for September/October/November/December 2011/January/February/March 2012

Categories

(Camino Graveyard :: Annoyance Blocking, defect)

Product:
Camino Graveyard
Component:
Annoyance Blocking
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: alqahira, Assigned: alqahira)

References

Details

(Whiteboard: [camino-2.1.3])

Attachments

(1 file)

Seven-month omnibus
4.87 KB, patch
stuart.morgan+bugzilla
: superreview+
Details | Diff | Splinter Review 
Old MacMadisonAve had an ad, e-i-e-i-o…
On login.yahoo.com:

<div id="iframeHolder">
<iframe height="1200" frameborder="0" width="1920" onload="loadTime = new Date().getTime();" scroll="no" src="https://login.yahoo.net/login_superads/us/superads_iframe_content.html?es=VuUwkn_51u9MeizDrKk-&b=8ti0a550nh786%26b%3D4%26d%3DktxEsTFpYEKdHQle1fEewBUmh8DAiZ1lqhbJAA--%26s%3Dli%26i%3D0VUR7bujvaa0zAZONMFe%26i%3D6ox4yTnM113Xk8gscduH" id="adFrame" title="Advertising by Yahoo!" style="visibility: visible;"/>
Summary: Omnibus ad-blocking bug for September 2011 → Omnibus ad-blocking bug for September/October 2011
I don't know if we care, but there are ads *everywhere* on

http://www.newzimbabwe.com/news-6349-Hooker+turns+into+donkey,+court+hears/news.aspx

(SFW, but a little on the questionable side if you have a conservative boss.)
On the redesigned independent.co.uk small ads sneak by in the masthead. The whole block is wrapped in <div class="x940 promoAndLeaderboard"> .... </a>

--> div[class~="promoAndLeaderboard"]
On http://www.businessweek.com/magazine/apples-supplychain-secret-hoard-lasers-11032011.html there are a bunch of sponsored links to random places in the sidebar.

Nothing really unique with which to block them, but 

div[id="bw_mall"]

might work.
To add insult to injury, on Gmail at the bottom of the conversations, there's an ad:

<div class="nH PS" style=""><div item="2086297690_7673826610" class="Zs"><div style="float:left"><a class="e Zu" href="http://pagead2.googlesyndication.com/[..]">NEW HTC Radar</a><a class="e Zu" href="http://pagead2.googlesyndication.com/[...]"> - </a><a class="e Zu" href="http://pagead2.googlesyndication.com/[...]">Made Easy w/ Windows Phone. In the</a></div><div style="float:right"><span class="Zw">Ads</span></div><div style="clear:both" class="PV"><span class="Zt">Right Hands it Brings You Closer.</span></div><div style="clear:both"><span dir="ltr"><a dir="ltr" class="Zv" href="http://pagead2.googlesyndication.com/[...]">www.htc.com/Radar</a></span> </div></div></div>

div[class="nH PS"] inside the Gmail @-moz-document block appears to block it.
Summary: Omnibus ad-blocking bug for September/October 2011 → Omnibus ad-blocking bug for September/October/November 2011
http://internacional.elpais.com/

banners at top of page

<div class="envoltorio_publi estirar">
	<div class="publi728_elpais">...</div>
	<div class="publi220_elpais">...</div>
</div>

advertising content(iframes) is mostly blocked, not always.

I block on div[class~="envoltorio_publi"] but div[class^="publi"] is another option.
(In reply to Smokey Ardisson (back-ish; no bugmail - do not email) from comment #5)
 
> div[class="nH PS"] inside the Gmail @-moz-document block appears to block it.

That messes up the layout a little - the footer part is then flush close to the textarea for quick reply

div.nH.PS {visibility: hidden !important; } /* or div[class="nH PS"] */
works better - in this case.

(it annoyed my partner enough that I looked for a solution…)
On  http://www.petfinder.com/petdetail/21878898?photo_view=2

we're getting a false-positive on <div id="photo-ad">. I don't know if there's anything we can really do about it or not (the ads there are more obviously labeled), but yeah.
(In reply to Chris Lawson from comment #11)
> On  http://www.petfinder.com/petdetail/21878898?photo_view=2
> 
> we're getting a false-positive on <div id="photo-ad">. I don't know if
> there's anything we can really do about it or not (the ads there are more
> obviously labeled), but yeah.

Ugh.  I'm loath to remove a $="-ad" rule (it comes from bug 583673 comment 2, fwiw), especially since that rule blocks actual *ads* on that page.

I've never heard of this site before; is it very popular?  If so, we can consider adding a global exception for it, but otherwise, edit user_ad_blocking.css to add your own exception unblock the content.
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #12)
> I've never heard of this site before; is it very popular?  If so, we can

It's the site that almost every animal shelter in the US uses to show their adoptable pets, but I have no idea what its Alexa rank might be.

cl
(In reply to Chris Lawson from comment #13)
> It's the site that almost every animal shelter in the US uses to show their
> adoptable pets

That's a good enough argument, I think.

> but I have no idea what its Alexa rank might be.

Currently #628 in the United States, so, yeah: http://www.alexa.com/siteinfo/petfinder.com

We should add an exception for petfinder.com for <div id="photo-ad">.
Summary: Omnibus ad-blocking bug for September/October/November 2011 → Omnibus ad-blocking bug for September/October/November/December 2011/January 2012
Via the forums:
http://forums.mozillazine.org/viewtopic.php?p=11709035#p11709035

content blocked on an ESPN games page
http://streak.espn.go.com/en/entry?date=20120206

<div class="games-fullcol fullcol-nouniv two_col_ad_in_rightcol" id="mgmain">

blocked by div[class*="_ad_"]
On StackOverflow:

img src="http://static.adzerk.net/Advertisers/*.png"
div id*="adzerk"

Either one or both should take care of it.
On http://www.inforum.com/event/article/id/350752/group/homepage/

div id="marketplaceDeal_widget"

Looks like some kind of employment ads, I think.
On http://www.swcbulletin.com/event/article/id/20138/

div id="marketplaceDeal_widget"

Hey, look, that's the same thing as in comment 17 :-p (This site doesn't use them for employment ads, though.)
Summary: Omnibus ad-blocking bug for September/October/November/December 2011/January 2012 → Omnibus ad-blocking bug for September/October/November/December 2011/January/February/March 2012
On http://twitpic.com/8r4flx, an awful fake WinXP alert dialogue ad for pediatric surgery:

<iframe width="300" scrolling="no" height="250" style="padding-top: 10px;" src="http://display.advertise.twitpic.com/"/>
On http://www.file-upload.net/download-4176779/Camino_2_1_2_RC_german.zip.html:

<iframe width="300" scrolling="no" height="250" frameborder="0" src="http://d.afdads.com/widget/render/hash/19a8953c644a828761cfb553a36c34d9" style="border: 0pt none;" allowtransparency="true"/>
WaPo has succumbed to the user-hostile "let's replace our front page with a full-window Flash ad" syndrome, and once again the "prevent users from clicking on things they actually want to read" div is still present.

div[id^="VwPanl"] { display: none !important } should fix it.
On the AJC obituary pages (via legacy.com), some really tasteless ads inside iframes like:

<iframe width="300" scrolling="no" height="250" frameborder="0" allowtransparency="true" marginwidth="0" marginheight="0" vspace="0" hspace="0" noresize="" src="http://media2.legacy.com/adiframe/3.0/5306.1/1369112/0/-1/size=300x250/adtech;alias=legacy.atlanta.searchresultsbrowse.300x250.1.1;target=_blank;kvcobrand=atlanta;kvusecname=0;kvquantcast=D;grp=493742750;misc=2446956701" id="a_dd5081f5-640f-4f9b-861b-4f685de7c724"/>

--> iframe[src*="/adiframe/"]
On the refreshed lemonde.fr – ads are blocked (most at least, except for some annoying things on the front page [*] that change markup with the weather… :-p), but some ad-containers still take huge amount of space:

div[class*="position_pub"] { display: none !important; } deals with it.


[*] mostly in the background (top/sides): div[id^="pmxxxxxx"] where xxxxxx changes continually (also visible on Lepoint.fr and other French news sites)
eg pmWonderWideContainer7708_1, pmBGContainer7708_1
They use background images pointing to http://broadcast.piximedia.fr
then overlay empty, absolute positioned a[href]'s.
real mess to block.
(In reply to Chris Lawson from comment #2)
> I don't know if we care, but there are ads *everywhere* on
> 
> http://www.newzimbabwe.com/news-6349-Hooker+turns+into+donkey,+court+hears/
> news.aspx

Unfortunately, these are all in the form of
a[href="randomsite"] img[src^="../banners/"]
which isn't blockable on the <a> because of the randomness of the href, nor blockable on the img because "../banners/" isn't a string we can be sure are ads. :-(

(In reply to philippe from comment #8)
> > div[class="nH PS"] inside the Gmail @-moz-document block appears to block it.
> 
> That messes up the layout a little - the footer part is then flush close to
> the textarea for quick reply

Talked with philippe about this; I don't see it and he says it's not nearly as bad as before, so let's keep using display:none everywhere.

Aside from those, this fixes everything mentioned here as well as bug 736917.

Also, if we get past three months ever again, someone needs to stage an ad-blocking update intervention :-(
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Attachment #608972 - Flags: superreview?(stuart.morgan+bugzilla)
Comment on attachment 608972 [details] [diff] [review]
Seven-month omnibus

sr=smorgan
Attachment #608972 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
http://hg.mozilla.org/camino/rev/8878d9d416a8
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: camino2.1.3? → camino2.1.3+
Resolution: --- → FIXED
Whiteboard: [camino-2.1.3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: