Adblock Plus and (a little) more

CSS property matching improvements · 2016-11-14 13:05 by Felix Dahlke

About a year ago, we introduced CSS property filters as a means of hiding elements based on their styles. Today, we have landed two improvements to this:

Case insensitive matching

This is a change in semantics; CSS properties will now always be matched in a case insensitive manner, to make it consistent with the way Adblock Plus matches URLs. This is unlikely to result in undesired behaviour as there shouldn’t be many use cases for case sensitive property matching.

Regular expression matching

Until now, CSS properties could only be matched using the simple URL matching syntax, which made it difficult to match property values in a fine-grained manner. To address this, properties can now optionally be matched using regular expressions. The default matching behaviour is still the same, to use regular expressions, a matching expression needs to start and end with /, for example:[-abp-properties='/width: 3[2-8]px;/']

These improvements are available in Adblock Plus for Firefox as of and Adblock Plus for Chrome and Opera as of, and will presumably be released with the next stable version on each platform respectively.

Please note that we still consider CSS property filters an experimental feature, and therefore subject to change. Considering this, and the fact that CSS property filters are slower than regular element hiding rules, they should only be used as a last resort.

To the install page

Read more Comment


New development build of Adblock Plus for Internet Explorer is available · 2016-10-19 10:17 by Oleksandr Paraska

A new development build of Adblock Plus for Internet Explorer is finally available. The most important change in this version is the change to the element hiding functionality. As of this version on IE10+ the element hiding will be done in a similar way as in our other extensions.

Read more

New element hiding approach in Firefox · 2016-10-10 15:46 by Wladimir Palant

Traditionally, element hiding on Firefox worked quite differently from all other platforms supported by Adblock Plus. Rather than decide on the filters for each website individually, all element hiding rules would be written into a single elemhide.css stylesheet file that would apply to all websites unconditionally. This approach had a few disadvantages:

  • The global stylesheet could not consider exceptions, such as websites where a particular rule should not apply — we had to implement a complicated mechanism to make sure that the rule didn’t have any effect in such cases, and on some websites there still were side-effects.
  • Changing a single element hiding rule caused the global stylesheet to apply again to all open tabs, this could cause significant delays.
  • With multiprocess Firefox coming up and sandboxing enabled on some platforms, we could no longer rely on being able to access that file.

Luckily, Firefox implemented better mechanisms to apply stylesheets to documents a while ago and as of Adblock Plus development build we are now taking full advantage of these. We will now make a separate decision for each website, which (if any) element hiding rules should apply. And we don’t sacrifice performance for that because the majority of element hiding rules will go into a preloaded stylesheet with all the rules which apply unconditionally.

There are a few drawbacks here:

  • New element hiding rules will no longer apply immediately, just like blocking rules they now require the document to be reloaded (can actually be seen as a good thing because consistent). This also affects Element Hiding Helper extension which will need to be updated.
  • We are no longer able to count hits for element hiding exception rules (issue 4509). We simply don’t know any more whether the rule that the exception applies to would have matched anything.
  • Element hiding rules apply with a slight delay which in theory might cause some ads being shown and then flashing out. In practice, I haven’t seen this yet.

This is a huge change to the inner workings of Adblock Plus and while we tested it quite thoroughly some issues are expected — let us know if you notice any.

To the install page

Read more Comment [2]


New filter type option for WebSockets · 2016-09-21 14:30 by Wladimir Palant

Starting with Adblock Plus 1.12.2 for Chrome, Opera and Safari we can block connections initiated via WebSockets on all major platforms (this functionality was available on Firefox since the very start). However, we didn’t have a special type for these requests as these were listed with type “other” instead. The assumption was that the protocol ws:// or wss:// would be sufficient for filter list authors in order to target WebSocket connections specifically. However, we received feedback that this wasn’t the case.

So with the current development builds (Adblock Plus for Firefox and Adblock Plus for Google Chrome, Opera and Safari) WebSocket connections are listed with the new type “websocket.” Consequently, filters can be made to target such connections specifically by adding $websocket type option. Existing filters will have to be duplicated for now:


This syntax will support both new and old Adblock Plus versions as long as the versions without support for the “websocket” type are still common (these will ignore the first filter).

To the install page

Edit (2016-09-22): This post was originally suggesting specifying both websocket and other options on one filter. This approach will not work in Adblock Plus versions without support for the websocket option because filters with unknown options are ignored.

Read more Comment [2]


Experimental Safari Content Blocking support · 2016-05-18 14:54 by Dave Barker

With Safari 9 Apple announced support for Content Blocking Extensions, with the aim of providing a more efficient way for Safari extensions to block adverts. (At the same time they announced the depreciation of the old method Safari extensions use to block adverts, implying it is likely to be removed from future Safari versions.) Since then we have been working on adding experimental Content Blocking support to Adblock Plus (issue 3687). It will be available as of Adblock Plus 1.12 for Safari and is now in the developments builds as of

Content Blocking can be enabled from the options page for supported versions of Adblock Plus and Safari:

Safari Content Blocking experimental option

But wait! Before you give it a try, here are some things you should know:

  • Safari disables the old method we use to block adverts when Content Blocking is enabled. This means that after disabling Content Blocking you will need to restart Safari.
  • To support Content Blocking we translate Adblock Plus filters to Content Blocking rules. While we’re working to improve this it is still a fairly slow process, you may notice a small delay when enabling Content Blocking or when adjusting your filters and subscriptions. (Each change causes the Content Blocking rules to be regenerated.)
  • Adblock Plus filters do not translate perfectly to Content Blocking rules, which means that some filters simply won’t work at all and some other filters may not work exactly as before.
  • Safari 9 has a limit of 50,000 Content Blocking rules, causing an error to be shown when exceeded: “Extension compilation failed: Too many rules in JSON array.”. If you see this error try disabling some filter list subscriptions. We are working to further compress the Content Blocking rules generated and also hope that Apple will increase this limit in future versions of Safari.

To the install page

Read more


“Block element” dialog now displayed as a popup window · 2016-02-18 17:14 by Dave Barker

We’ve been working on some changes to the “Block element” feature. These changes will be available in Adblock Plus 1.11 for Chrome, Opera and Safari and now in development builds as of

The “Block element” feature allows you to select elements on the current page and generate filters to block them. After selecting an element the “Block element” dialog is displayed which allows you to confirm the filters that should be added. For Chrome and Opera this dialog is now displayed as a popup window (issue 2426) instead of as part of the website itself. In Safari the dialog will open as a new tab instead. (This is because Safari unfortunately doesn’t provide an equivalent way for us to open popup windows.)

This change should resolve a number of issues with the “Block element” dialog, most importantly one that was being used by websites to reliably detect if Adblock Plus was installed.

To the install page

Read more Comment


Bringing "blockable items" to Chrome, introducing the Adblock Plus developer tools panel · 2016-02-03 18:08 by Sebastian Noack

Since we ported Adblock Plus to Chrome, we promised our users feature-parity with Adblock Plus for Firefox. While we are still not there, the probably most significant feature that has been missing on Chrome for a long time – but not anymore – is a way to view blockable items/requests along with applied filters.

For Chrome and Opera, we decided to implement “blockable items” as a developer tools panel (issue 154). Being a tool for advanced users, filter list authors and our own developers, we think that it belongs there. And integrating it with the developer tools gives a nice user experience.

screenshot demonstrating the new Adblock Plus developer tools panel

The developer tools panel is now available in the development builds as of Adblock Plus for Chrome and Opera, and will be included in the next release, Adblock Plus 1.11. In order to use the developer tools panel, inspect the current page (Ctrl + Shift + I) and click on the “Adblock Plus” panel. Unfortunately, Chrome currently doesn’t provide a way to open the developer tools panel programmatically, e.g. from our icon menu.

Also as opposed to “blockable items” on Firefox, we don’t record items in advance, to avoid performance penalties and additional memory usage while not using the developer tools panel. Therefore you have to (re)load the page, with the panel open, to see all items.

The items shown in the developer tools panel include:

  • Web requests as seen by Adblock Plus. Blocked/Whitelisted requests are indicated red/green, with the responsible filter given in the right column. When moving the mouse over a request item, buttons – to block or whitelist the request – appear.
  • Element hiding filters that match and hide any element on the current page. However, since Chrome doesn’t provide a way to detect actual element hiding hits, these items are simulated by observing the document for hidden elements that match the selector of any active element hiding filter, which might not give completely accurate results in rare situations.
  • Document-based whitelisting including DOCUMENT, ELEMHIDE, GENERICBLOCK and GENERICHIDE exception rules, that apply for any document on the current page. Note that if a DOCUMENT exception rule applies, there won’t show any further items – as it pretty much disables Adblock Plus – for that document.

To the install page

Read more Comment [4]


Finished support for multi-process Firefox · 2016-01-11 12:58 by Wladimir Palant

We continued working on improving our support for multi-process Firefox. So far we have still been relying on backwards compatibility code in Firefox which is slow and error-prone. However, starting with Adblock Plus development build that backwards compatibility code no longer applies to Adblock Plus — now we are on our own. As far as I know, all issues have been resolved, with one exception:

  • Element hiding functionality isn’t working on Mac OS X when multi-process is enabled (bug 1187099). Mozilla is fixing this, we might also implement our own workaround however.

This development build is a release candidate for Adblock Plus 2.7.1 which we plan to release on January 19, 2016. Please tell us if you notice any other issues, particularly around Blockable items list and Issue reporter.

To the install page

Read more Comment


Reintroducing the $ping filter option · 2015-12-23 16:59 by Sebastian Noack

Historically, there has been the $ping filter option in Adblock Plus, to limit request blocking filters to the URL given by the ping attribute on links. When such a link is clicked, the browser sends a request to that URL in the background. This technique is mostly useful for tracking. However, it has never been enabled by default in Firefox. Therefore, with Adblock Plus 2.0, $ping got deprecated and merged into $other.

But recently navigator.sendBeacon() got introduced, which is basically the JavaScript equivalent of the ping HTML attribute. And it is enabled by default. Moreover, on Chrome, <a ping> is supported by default too. And starting with Chrome 49, it’s possible to distinguish these requests from others.

Therefore, we are reintroducing the $ping filter option (issue 3452). Starting with Adblock Plus for Firefox and for Chrome/Opera, filters using the $ping option will only match requests that are either caused by <a ping> or by navigator.sendBeacon(). Note that the filter option $other won’t match these requests anymore.

To the install page

Read more Comment [1]


New CSS property filter syntax · 2015-12-16 17:42 by Dave Barker

We have created a new element hiding rule syntax which allows for the matching of elements based upon the rules applied to them from any stylesheets1. The new syntax is available now in development builds of Adblock Plus for Chrome, Opera and Safari as of and will be released early next year in version 1.10. Support in Adblock Plus for Firefox is under development and will follow.

This is an advanced and experimental feature that is still subject to change.

“the matching of elements based upon the rules applied to them from any stylesheets.” is quite a mouthful! What does that mean?

Well let’s say there’s a webpage that has the following stylesheet:

.foobar {
  width: 32px;

…and the following HTML fragment somewhere in the page:

<div class="foobar"><p>Hello world</p></div>

You could write a CSS property based element hiding rule to hide the div like this:[-abp-properties='width: 32px;']

Wildcards are also supported, so any of these would work as well:[-abp-properties='width: *px;'][-abp-properties='*: 32px;'][-abp-properties='width: 3*px;']

They can also be combined with selector matching. This rule would hide just the child paragraph tag:[-abp-properties='width: 32px;'] > p

Syntactically they are just like normal element hiding rules, the magic is in the special -abp-properties “attribute”2. Its value is checked against any rules from all stylesheets that apply to the element. For our examples the property width: 32px; of the rule in our stylesheet does match and so the element is hidden.

That all seems pretty convoluted, why couldn’t we just write a rule that matched for the foobar class directly?

It’s true that in the previous example we could have matched the foobar class much more easily with a rule like this:

The problem is that there is not always an easy way to match elements with a standard selector. Some websites have started to randomize their page structure in an attempt to circumvent ad blockers. The new CSS property filters should empower filter authors to hide adverts consisting of dynamically generated HTML and CSS as long as some of the values and/or properties of applied CSS rules are predictable.

Caution! CSS property filters are slower than normal filters and will slow down the page they are applied on. They must always be restricted to a domain and should only be used as a last resort.

To the install page

1 As originally given in the stylesheet. Not to be confused with computed styles as shown by the inspector.

2 Actually for older versions of Adblock Plus that don’t yet support CSS property filters this rule really will be interpreted as matching elements with a matching -abp-properties attribute. This way filter lists can contain CSS property filters whilst still being otherwise backwards-compatible with versions of Adblock Plus that don’t support them yet.

Read more Comment