[adblocking] ad_blocking.css is too non-specific (breaks tinderbox)



Camino Graveyard
12 years ago
12 years ago


(Reporter: Simon Fraser, Assigned: Mike Pinkerton (not reading bugmail))





12 years ago
Some of the rules in ad_blocking.css are way too general, and may break a lot of
legitimate sites.

I don't think our ad blocking should block anything based purely on dimensions.
It should also not block stuff like tables or divs with specific sets of style
rules. I think rules like
are also too generic.
Don't you mean userContent.css?  

The ad_blocking.css I have is from December and it's essentially empty
        display: none !important;
and deleting it and re-enabling ad-blocking doesn't make it reappear.

That said, see bug 296783 where we've been collecting the problems people have
reported already.
Summary: ad_blocking.css is too non-specific (breaks tinderbox) → [adblocking] ad_blocking.css is too non-specific (breaks tinderbox)
The ad-blocking css at http://www.mozilla.org/support/firefox/adblock has in it:
- div[id*="popup"],
As does the ad-blocking css at
- div[id*="popup"],

Which breaks tinderbox because of:
<style type="text/css">
#popup {
  position: absolute;
  margin: -5em 0 0 -5em;
  opacity: 0.9;
  border: 0px;
  height: 8em;
  width: 16em;
.note#popup {
  width: 25em;
.log#popup {
.note#popup, .log#popup {
  border: 2px solid black;
  background: white;
  color: black;
  padding: 0.5em;

So can't the css styling for the tinderbox page be changed to use a name that is
 less likely to be blocked?

Comment 3

12 years ago
I don't think it should. "popup" is way too generic, and is probably used on
lots of legitimate sites.
Adblocking is a real problem; it really needs to be done with finely honed
surgical precision, and it's intensely personal (things that need to be blocked
vary by the body of sites one visits).  Our current method is rather like taking
a chainsaw in order to come up with a limited set of rules that block most ads
for most people.

Second, most users aren't going to have any idea how to remove or edit the rules
to fix pages that get broken (it's as foreign to them as fixing Camino code is
to me), so you either say "turn off adblocking" or it falls to the triagers to
pore through the site and the adblocking css to find and tweak the offending rule.

Third, updates are not dynamic (quit, edit rule, restart) nor can we push an
update from this end (at least not without dataloss for anyone who's already
customized their userContent.css); no one who has already been using the
adblocking feature will ever see Simon's checkin tonight--unless they disable
adblocking, quit Camino, restart and re-enable adblocking, quit, and restart.

I've been wondering if we should just punt on this feature and suggest everyone
use CamiBlock (which uses hostperm.1 and the permissions extension to enable
blocking of images, scripts, plugins, by host, with an optional 3rd-party
blacklist to download to kick-start the blocking).  Host-based blocking is a bit
more finely-tuned than assorted DIV sizes and *[src*="ad*"] type rules.

At the very least, this should be one of the areas that we push for
testing/feedback in 0.9b.  So far in the 0.9a cycle the issues on bugzilla, the
forums, and the list have been less numerous than I feared initially, but I
imagine the sample size of Camino users is still very small in the alpha world
and skews towards people who, in some cases, might even be able to "fix" the CSS
when they have a problem.

Adding some folks to the cc list so we can discuss :-)
Just to clarify, "Adblocking is a real problem" should really have been written
as "Doing adblocking well is a real problem" or something similar; I don't
consider adblocking in and of itself a problem :-)

Comment 6

12 years ago
*** Bug 303828 has been marked as a duplicate of this bug. ***

Comment 7

12 years ago

*** This bug has been marked as a duplicate of 296783 ***
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.