Opened on 05/19/2014 at 03:54:06 PM

Closed on 06/29/2016 at 07:02:05 PM

Last modified on 10/07/2016 at 07:58:03 AM

#521 closed change (fixed)

Inject our stylesheet on per-site basis rather than globally

Reported by: trev Assignee: trev
Priority: P3 Milestone: Adblock-Plus-2.8-for-Firefox
Module: Adblock-Plus-for-Firefox Keywords:
Cc: fhd, arthur, greiner, mapx, saroyanm, Compuitguy, trev, famlam Blocked By: #4139, #4221, #4227, #4500
Blocking: #524 Platform: Firefox
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by trev)


Currently we register a large global stylesheet in Firefox, it is being applied to every single webpage. According to there is no memory use advantage however, essentially a copy of this stylesheet is being injected into each document.

What to change

We can stick to a single stylesheet file for now and merely decide individually on whether we want to inject it into a webpage. We can listen to some notification like content-document-global-created and use nsIDOMWindowUtils.loadSheet() to inject the stylesheet. This will solve several issues:

  • No stylesheet is injected into whitelisted pages and pages where element hiding is disabled - meaning also no side-effects from element hiding that were unavoidable so far.
  • The ugly protocol whitelist for generic rules can go, we simply won't inject the stylesheet into chrome:// documents and such.
  • More consistent behavior - changes to element hiding rules apply only after page reload, same as with other filters.
  • No hang when Adblock Plus is enabled or disabled globally coming from the stylesheet being injected into all open tabs simultaneously.
  • We can get rid of the current ugly approach to implement exceptions via -moz-binding once bug 349813 is fixed.

Attachments (0)

Change History (52)

comment:1 Changed on 05/19/2014 at 03:58:29 PM by tschuster

I will try to prototype this.

comment:2 Changed on 05/19/2014 at 04:38:46 PM by trev

  • Description modified (diff)

comment:3 Changed on 05/19/2014 at 05:04:36 PM by trev

  • Owner set to tschuster

comment:4 follow-up: Changed on 05/19/2014 at 05:21:44 PM by tschuster

  • The ugly protocol whitelist for generic rules can go, we simply won't inject the stylesheet into chrome:// documents and such.

I think if we use "content-document-global-created" we are guaranteed not to inject into chrome :)

  • More consistent behavior - changes to element hiding rules apply only after page reload, same as with other filters.

Perfect, if we had to apply changes immediately this would turn out be rather difficult.

comment:5 Changed on 05/19/2014 at 08:03:07 PM by mapx

  • Cc added

comment:6 in reply to: ↑ 4 Changed on 05/19/2014 at 08:49:30 PM by trev

Replying to tschuster:

I think if we use "content-document-global-created" we are guaranteed not to inject into chrome :)

content-document-global-created is about the distinction between chrome and content meaning which side of the security boundary you are on - it isn't about privileges. Privileged documents can be loaded into the content area (e.g. Add-ons Manager page).

comment:7 Changed on 05/20/2014 at 06:09:07 AM by trev

  • Blocking 524 added

comment:8 Changed on 05/20/2014 at 06:14:08 PM by tschuster

  • Review URL(s) modified (diff)

comment:9 Changed on 05/20/2014 at 06:14:36 PM by tschuster

I just uploaded a patch for this. It seems to work correctly for me, but probably not a final version.

comment:10 Changed on 06/11/2014 at 07:15:31 AM by philll

By tschuster:
So, just to update this bug. I recently uploaded a version of this patch that is almost finished. Sadly this regresses memory usage, because now we have more style-sheet memory per window. I talked to bz about this and he suggested that we add an API to Gecko, which would allow us to cache one global stylesheet and just load a reference to it in every window. I want to spend some time to figure out if this is something I can do easily. That new API should put as at slightly better memory usage. And as a next step we can probably split the css in two, one global css that gets loaded in every window and one css with just the domain specific rules, if they exist.

comment:11 Changed on 06/25/2014 at 08:10:50 AM by trev

  • Blocking 717 added

comment:12 Changed on 06/25/2014 at 08:40:15 AM by trev

  • Component changed from Extensions-for-Adblock-Plus to Adblock-Plus-for-Firefox

comment:13 Changed on 06/25/2014 at 09:06:17 AM by trev

  • Blocking 717 removed

comment:14 Changed on 07/03/2014 at 01:30:31 PM by arthur

  • Platform set to Unknown

Would this fix the follwing issue?

  1. Update EasyList
  2. Add these 3 filters: ##.banner300x250, ##.banner300x100 & ###sponsored-ad
  3. Go to this page and notice the anti adblock message
  4. Add these 3 whitelists:, &
  5. Reload the page and notice the anti adblock message still appears
  6. Remove the filters and whitelists and notice the message doesn't show up, the video appears instead

This doesn't happen in Chrome. It works when you add the whitelists.

comment:15 Changed on 07/03/2014 at 01:58:09 PM by trev

Yes, it would fix that issue.

comment:16 Changed on 07/09/2014 at 12:38:11 PM by philll

  • Platform changed from Unknown to Firefox

comment:17 Changed on 07/21/2014 at 08:29:17 AM by saroyanm

  • Cc added

comment:18 Changed on 07/27/2014 at 10:20:32 AM by arthur

  • Cc arthur added

comment:19 Changed on 08/06/2014 at 09:19:11 AM by arthur

Is it possible to estimate when this will be ready? In order to counteract a certain video fallback ad mechanism that is being used on some big German sites I have to disable generic element hiding filters because an element hiding whitelist doesn't work as it should in Firefox.

comment:20 Changed on 08/06/2014 at 04:34:48 PM by tschuster

It would be interested in understanding how my patch helps there. Anyway I just uploaded a new version. I am not sure when it's read, this depends on what Wladimir or anybody else finds during review and how complicated this is to address.

comment:21 Changed on 10/31/2014 at 07:08:23 PM by archon810

Looks like is affected by this bug. Is there any idea if it's going to be fixed any time soon please?

Thank you.

comment:22 Changed on 01/22/2015 at 01:11:26 AM by archon810


Any plans to fix this issue? It's still affecting the plugin and our sites.

Thank you.

comment:23 Changed on 02/12/2015 at 04:29:21 PM by greiner

  • Cc greiner added

comment:24 Changed on 02/12/2015 at 04:47:34 PM by mapx

  • Cc mapx saroyanm added; removed

comment:25 Changed on 06/17/2015 at 07:57:47 AM by Compuitguy

How can we vote/cc for this ?

comment:26 Changed on 06/17/2015 at 08:03:14 AM by mapx

it's under review (last activity 8 months ago ...)

comment:27 Changed on 06/17/2015 at 08:41:49 AM by Compuitguy

Yes, saw that

So there is no possibility to vote/cc for issues ?

comment:28 Changed on 06/17/2015 at 08:44:05 AM by mapx

  • Cc Compuitguy added

comment:29 Changed on 06/17/2015 at 09:31:32 AM by Compuitguy

Thanks mapx


There is progress on this bugzilla issue which is related

77999 – share rule processors for XUL, scoped, UA, and user stylesheets

comment:30 Changed on 06/26/2015 at 03:59:22 PM by Compuitguy

77999 – share rule processors for XUL, scoped, UA, and user stylesheets


Target Milestone: mozilla41

From the bug:

ABP is enabled, using its default blocklist, we save a bit over 2 MB per document. (This is for every displayed document, including iframes, except one, since we are now sharing this data between documents.)

Without ABP, we just have the standard UA style sheets that Firefox adds to every document, and in that case we save about 120 KB per document.

We also save the time required to build up these tables, but I haven't measured that.

comment:31 Changed on 07/20/2015 at 11:32:17 AM by trev

  • Cc trev added
  • Ready unset
  • Tester set to Unknown

@tschuster: Does fixing this still make sense given that bug 77999 has been resolved?

comment:32 Changed on 07/21/2015 at 10:42:02 AM by tschuster

  • Resolution set to rejected
  • Status changed from new to closed

Not really. I see no way this is going to reduce memory below that what we have after fixing bug 77999.

comment:33 Changed on 07/24/2015 at 10:16:55 AM by arthur

Still there is the issue where Google ads embedded with the responsive Adsense code will not show up if you disable Adblock Plus for a specific domain (e. g., tested with Nightly 42.0a1 (20150723030207) and Adblock Plus with EasyList only). Whitelisting those in Acceptable Ads in Firefox doesn't work then.

Should I create a new issue for that?

comment:34 Changed on 08/16/2015 at 04:23:07 PM by mapx


test using 42.0a2 (2015-08-15)
tested also in 41.0b1

go to
now you should add:

keeping easylist enabled does not work
disabling easylist and adding easylist without hiding filters ==> will work

Last edited on 08/16/2015 at 04:27:42 PM by mapx

comment:35 Changed on 08/16/2015 at 04:24:06 PM by mapx

  • Resolution rejected deleted
  • Status changed from closed to reopened

comment:36 Changed on 08/20/2015 at 08:24:32 AM by jobp

  • Cc added

comment:37 Changed on 08/20/2015 at 11:27:19 AM by arthur

  • Cc famlam added; removed

comment:38 Changed on 08/20/2015 at 12:33:53 PM by tschuster

"keeping easylist enabled does not work" What do you mean exactly?
When visting this site I get some kind of warning about using an Adblocker, which makes this site unusable. Is it that?

comment:39 Changed on 08/20/2015 at 01:53:53 PM by mapx

if you use easylist and add the new filter

the site will work fine in ABP for chrome but not in ABP for firefox and this due to the old bug with stylesheets. It will work only if you use easylist without hiding filters. And this even if in easylist we have the whitelisting filter


see also

and the comments of Wladimir (not only here but also on blog) which indicates this issue as a consequence of 521

Last edited on 08/20/2015 at 01:57:06 PM by mapx

comment:40 Changed on 08/20/2015 at 02:02:17 PM by mapx

comment:41 follow-up: Changed on 08/20/2015 at 02:06:59 PM by tschuster

Mhm I guess per-site filtering would probably fix this, but this doesn't mean we can't fix it in another way. I will look into it.

comment:42 in reply to: ↑ 41 Changed on 12/07/2015 at 03:11:50 PM by mapx

Replying to tschuster:

Mhm I guess per-site filtering would probably fix this, but this doesn't mean we can't fix it in another way. I will look into it.

still nothing ? very old bug.

another test case:

the filters already in easylist are working fine in ABP for chrome
in firefox still present the anti adblock message
tested also adding


does not work.

It's working only switching to easylist without element hiding.

comment:43 Changed on 02/04/2016 at 11:40:39 AM by trev

  • Priority changed from P2 to P3
  • Ready set

We still want to tackle this but I think P3 is more realistic.

comment:44 Changed on 06/17/2016 at 10:08:50 AM by trev

  • Blocked By 4139 added
  • Owner changed from tschuster to trev

Tom, hope you don't mind me taking this. I've done some preparation work for this and #524 in #4139, it should be fairly simple now.

comment:45 Changed on 06/17/2016 at 02:11:29 PM by trev

  • Review URL(s) modified (diff)
  • Status changed from reopened to reviewing

comment:46 Changed on 06/29/2016 at 07:01:17 PM by abpbot

comment:47 Changed on 06/29/2016 at 07:02:05 PM by trev

  • Milestone set to Adblock-Plus-for-Firefox-next
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:48 Changed on 06/29/2016 at 08:27:01 PM by mapx

error in console on START (effect: the hiding filters are not working)

NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMWindowUtils.addSheet]

row code error (elemhide.js:346)

        utils.addSheet(this.sheet, Ci.nsIStyleSheetService.USER_SHEET);
Last edited on 06/29/2016 at 08:36:38 PM by mapx

comment:49 Changed on 07/04/2016 at 12:31:43 PM by trev

  • Blocked By 4221 added

comment:50 Changed on 07/04/2016 at 12:34:00 PM by trev

  • Blocked By 4227 added

comment:51 Changed on 07/04/2016 at 12:34:40 PM by trev

@mapx: I created #4227 for this regression.

comment:52 Changed on 10/07/2016 at 07:58:03 AM by trev

  • Blocked By 4500 added

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from trev.
Note: See TracTickets for help on using tickets.