348160 - Ad-blocking blocks attachments in Gmail

Status: RESOLVED FIXED

(Camino Graveyard :: Annoyance Blocking, defect)

Description

[froodian (Ian Leue)]

Snipping crucial bits from http://forums.mozillazine.org/viewtopic.php?t=449993

I don't see my .zip attachments in emails in my Gmail Inbox or Sent Mail.  Changing the user agent with CamiTools doesn't help. Opening the email in Gmail with Safari or Firefox 2.0b1 shows the zip file and allows it to be downloaded.  View Frame Source does appear to show the zipped file.

Smokey: "This seems to be related to ad-blocking somehow. Will someone please file a bug? I'll see if I can figure out which rule is causing the problem...."

Comment 1

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

Presuming Gmail didn't change their attachment div id recently, this was broken by one of the rules introduced in the July omnibus fix...I think to wack gofug... ads.

There's not a real clean way to fix it without backing out that rule (which would make many ads re-appear).

Comment 2

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

Actually, the fix doesn't look that ugly.  As always, we're at the mercy of the vagaries of Gmail's changing div ids and classes (e.g, we used to block the  ads in the right-hand column, but at some point they changed the ids and we don't now), but that's really no different than the rest of the web.

Instead of removing the blocking rule

div[id^="ad_"],

I added 

div#mb_0>div[id^="ad_"],

to the "turn some false positives back on" section.

Simon, is that solution OK, or would you prefer removing the rule instead?

Comment 3

[Simon Fraser [no longer active]]

(In reply to comment #2)

> div#mb_0>div[id^="ad_"],

This seems a little too susceptible to google changing their div ids.

Comment 4

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

This rule also seems to work:

@-moz-document domain(mail.google.com) {
div[id^="ad_"] {display: inline ! important }
}

Gmail's an important-enough site that we have to un-break it in our ad-blocking, but I don't know if it's an important-enough site to add a site-specific exception to our ad-blocking rather than remove the useful broad-spectrum rule to fix an extremely bone-headed div id that they've chosen to assign to a critical part of their email UI....

Comment 5

[Simon Fraser [no longer active]]

That's much better.

Comment 6

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

Attachment: Un-blocks the attachment block with @-moz-document rule for Gmail

Since this is a pretty serious regression (and one that people won't expect ad-blocking to be the cause of), it would be good to get this now rather than waiting for this month's omnibus ad-blocking fix.

Simon, if you like this, do you have trees to land this on the trunk and 1.8branch?  We're in a spell where no one with cvs access is around/doing any Camino work.... :(

Comment 7

[philippe (part-time)]

(In reply to comment #6)
> Created an attachment (id=233173) [edit]
> Un-blocks the attachment block with @-moz-document rule for Gmail

Can you make it:
@-moz-document domain(mail.google.com) {
div[id^="ad_"] {display: block ! important }
}

block instead of inline, 'block' being the default display value for a div.
Unless Google themselves set the display value for that div to inline. But I don't see that happening, according to the DomInspector with Fx trunk.

Comment 8

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

Attachment: uses block rather than inline

Per philippe, restores the div as block rather than inline.

Comment 9

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

kreeger and pink are both back now, so checkin won't be a problem anymore once this gets sr ;)

Comment 10

[Samuel Sidler (old account; do not CC)]

*** Bug 348581 has been marked as a duplicate of this bug. ***

Comment 11

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

kreeger, can you land this on 18branch and trunk ASAP?

Comment 12

[Samuel Sidler (old account; do not CC)]

(In reply to comment #11)
> kreeger, can you land this on 18branch and trunk ASAP?
> 

And the 1.8.0 branch, if possible. This is an important fix.

Comment 13

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

(In reply to comment #12)

> And the 1.8.0 branch, if possible. This is an important fix.

No, 1.8.0 is not needed; the original patch that caused this hasn't landed on 1.8.0 (that's why both this and bug 342956 have blocking? flags) ;)  

Depending on when we do 1.8.0, I'll probably post single diff with all the ad-blocking fixes to date, anyway.

Comment 14

[Mark Mentovai]

Checked in on the trunk and MOZILLA_1_8_BRANCH.

Comment 15

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

Attachment: Unified ad-blocking patch for 1.8.0 branch

This is the unified ad-blocking patch for 1.8.0 (this bug and bug 342956)

Comment 16

[Nick Kreeger]

Landed on the MOZILLA_1_8_0_BRANCH