Ad-blocking blocks attachments in Gmail

RESOLVED FIXED in Camino1.5

Status

defect
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: froodian, Assigned: alqahira)

Tracking

({fixed1.8.0.7, fixed1.8.1, regression})

Bug Flags:
camino1.0.3 +

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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...."
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).
Status: NEW → ASSIGNED
Keywords: regression
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?
Assignee: nobody → alqahira
Blocks: 342956
Status: ASSIGNED → NEW
Flags: camino1.0.3?
Summary: Adblocking blocks zip (and other?) attachments in gmail → Ad-blocking blocks attachments in Gmail
(In reply to comment #2)

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

This seems a little too susceptible to google changing their div ids.
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....
That's much better.
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.... :(
Attachment #233173 - Flags: superreview?(sfraser_bugs)
(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.
Per philippe, restores the div as block rather than inline.
Attachment #233173 - Attachment is obsolete: true
Attachment #233200 - Flags: superreview?(sfraser_bugs)
Attachment #233173 - Flags: superreview?(sfraser_bugs)
kreeger and pink are both back now, so checkin won't be a problem anymore once this gets sr ;)
*** Bug 348581 has been marked as a duplicate of this bug. ***
Attachment #233200 - Flags: superreview?(sfraser_bugs) → superreview+
kreeger, can you land this on 18branch and trunk ASAP?
Whiteboard: [needs checkin]
(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.
(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

13 years ago
Checked in on the trunk and MOZILLA_1_8_BRANCH.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
This is the unified ad-blocking patch for 1.8.0 (this bug and bug 342956)
Flags: camino1.0.3? → camino1.0.3+
Whiteboard: [needs checkin 180branch]

Comment 16

13 years ago
Landed on the MOZILLA_1_8_0_BRANCH
Keywords: fixed1.8.0.7
Whiteboard: [needs checkin 180branch]
You need to log in before you can comment on or make changes to this bug.