Ad-blocking blocks attachments in Gmail

RESOLVED FIXED in Camino1.5

Status

Camino Graveyard
Annoyance Blocking
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: froodian (Ian Leue), Assigned: Smokey Ardisson (offline for a while; not following bugs - do not email))

Tracking

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

1.8 Branch
Camino1.5
PowerPC
Mac OS X
fixed1.8.0.7, fixed1.8.1, regression

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 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

Comment 3

11 years ago
(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....

Comment 5

11 years ago
That's much better.
Created attachment 233173 [details] [diff] [review]
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.... :(
Attachment #233173 - Flags: superreview?(sfraser_bugs)

Comment 7

11 years ago
(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.
Created attachment 233200 [details] [diff] [review]
uses block rather than inline

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. ***

Updated

11 years ago
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

11 years ago
Checked in on the trunk and MOZILLA_1_8_BRANCH.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Created attachment 235151 [details] [diff] [review]
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)
Flags: camino1.0.3? → camino1.0.3+
Whiteboard: [needs checkin 180branch]

Comment 16

11 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.