Adblock Plus 1.13.5 for Chrome and Opera released · 2018-01-26 15:20 by Sebastian Noack
This is an emergency release, addressing a limitation in Chromium which caused pages to appear blank, starting with Google Chrome 66 (and respective future versions of Opera).
After Chromium added support for user style sheets, Adblock Plus detected this feature and began using it automatically. Unfortunately this caused problems, since Chromium did not handle the very long CSS selector lists, that Adblock Plus injects, as well as Firefox does. This caused pages to be rendered blank (issue 6298). With this emergency release we prevent Adblock Plus from using user style sheets for now (issue 5695), but we’ll start using them again soon.
Adblock Plus 1.13.4 for Chrome and Opera released · 2017-09-26 15:39 by Hubert Figuière
This release features improvements to the emulation filters, which allow to block ads on Facebook again. It also includes some bug fixes and changes under the hood.
- Properly handle hiding emulation in dynamically generated content (issue 5000 and 5438).
- Properly select the element when selecting pseudo-elements style properties in hiding emulation filters (issue 5339).
- Fixed some issue with
:-abp-has()(issue 5436 and 5422).
- Fixed an issue that caused added custom filters to show up twice in the options (issue 4978).
- Improved user notifications (issue 5558, 5460 and 5459).
Adblock Plus 1.13.3 for Chrome and Opera released · 2017-07-12 11:57 by Dave Barker
This release features a number of ad blocking improvements, bug fixes and some changes under the hood.
- Added WebRTC connection blocking support, since those connections were being abused by some websites to serve advertising (issue 4455, 5087 and 5092).
- Added support for the new advanced
#?#element hiding filter syntax, which includes the new
:-abp-haspseudo-class (issue 5094, 5220 and 5117).
- Added a workaround to prevent websites from abusing
contentDocumentAPIs to bypass ad blocking (issue 4586 and 5207).
- Started allowing web requests not associated with a browser tab to be blocked (issue 5042).
- Started using the
webRequestAPI for the blocking of WebSocket connections instead of our workarounds when supported by the browser (issue 5027 and 5130).
- Fixed a bug which prevented the “Hide targeted messages?” notifications from being displayed until the browser was restarted (issue 5019 and 5023).
- Reduced the number of “Blocked script execution…” warnings that Adblock Plus causes (issue 4494).
New #?# syntax for advanced element hiding rules · 2017-06-19 17:21 by Hubert Figuière
Starting with Adblock Plus 1.13.3 for Chrome and Opera (and development builds as of 220.127.116.112) there is a new and improved syntax which can be used for advanced element hiding filters. It allows for elements to be hidden based upon their contents using
:-abp-has. CSS property filters have also being adjusted to be consistent with the new syntax, so both those and
:-abp-has filters now use the
#?# option separator.
So for example here’s a standard element hiding filter:
Which with the new advanced syntax could be written as:
The overall syntax is the same, but
#?# filters have access to a few extensions implemented as CSS pseudo classes. This extra power comes with a cost however, the new
#?# filters are much slower and should only be used where necessary. The above example is bad therefore, since none of those extensions are being used. Filters using the new syntax must also be restricted to as few domains as possible, without any domain restrictions they are rejected outright.
So which CSS pseudo classes are supported?
:-abp-properties() (CSS property filters)
:-abp-properties() is a reworked syntax for the CSS property filter. The value of the
-abp-properties attribute becomes the argument passed to the pseudo-class selector. Your old filters will be converted automatically when loading the filter lists, and will work the same way. For example:
domain.com##[-abp-properties='background-color: rgb(0, 0, 0)']
domain.com#?#:-abp-properties(background-color: rgb(0, 0, 0))
Note the lack of quotes. As before, you can combine this into a more complex CSS selector.
With this change we introduced a new pseudo-class:
:-abp-has(selector). Inspired by the CSS Level 4 draft :has(), this pseudo-class selects an element if it contains something that matches the selector passed an argument.
domain.com#?#div.sidebar > div:-abp-has(> video.ad)
On the site “domain.com”, hide the element that has as direct descendant a
<video> element with the class “ad” and is a direct descendent of a
<div> that has the class “sidebar”. We want the enclosing element because it contain other things with want to hide.
domain.com#?#div.sidebar > div:-abp-has(> div.sidebartitle) > .adtext
On the site domain.com, hide the elements with the class “adtext”, that are direct descendent of a
<div> element that also has a direct descendent a
<div> with the class “sidebartitle”, and that is a direct descendent of a
<div> that has the class “sidebar”.
Note: It is recommended to not nest
:-abp-has() where possible, as that will further slow down element hiding. Also it is recommended that the selector inside a
:-abp-has() starts with a combinator like
~. Otherwise a lot of elements will be needlessly selected as more that one ancestor will match.
New filter type option for WebRTC connections · 2017-04-12 12:08 by Dave Barker
Starting with Adblock Plus 1.13.3 for Chrome and Opera (and development builds as of 18.104.22.1681) the blocking of WebRTC connections is supported. Those connections will have the new request type of “webrtc” and so filters can be made to target them by adding the
$webrtc type option.
WebRTC is an experimental browser technology which is supposed to be used for things like video conferencing. Unfortunately despite still being in active development it’s already being misused to serve adverts! Since Chrome does not yet allow WebRTC connections to be blocked by extensions directly (Chromium issue 707683), we’ve had to implement a workaround to achieve this.
Support for other platforms such as Firefox should follow soon, we’ll keep you posted.
Adblock Plus 1.13.2 for Chrome and Opera released · 2017-03-21 16:50 by Jon Sonesen
This is an emergency release, fixing a regression and preventing installation on unsupported Opera versions.
- Fixed a regression with the “Hide targeted messages?” notifications, which prevented the notification text from being displayed (issue 5014).
- Adblock Plus can no longer be installed on Opera 35 and older versions, which are incompatible (issue 4787).
Adblock Plus 1.13.1 for Chrome and Opera released · 2017-03-17 18:21 by Dave Barker
This is an emergency release, fixing overly eager popup blocking.
- Fixed a bug whereby popup windows containing iframes were sometimes blocked by mistake (issue 5009). While this was a pre-existing bug, it was made more serious by our recent popup blocking improvements (issue 4834).
Adblock Plus 1.13 for Chrome and Opera released · 2017-03-15 13:18 by Dave Barker
This is a major release containing some user interface improvements and more changes behind the scenes.
- Further improved our WebSocket (issue 4643, 4807) and popup (issue 4834) blocking capabilities.
- Improved the “Block element” tool, fixing a bug where the dialog window would sometimes fail to open (issue 4714) and another which very rarely caused the currently targeted element(s) not to be highlighted (issue 4603).
- Improved the “Add your own filters” interface in the Options page. Extremely large filters are now displayed properly (issue 1121), and the interface is much more responsive when dealing with large numbers of custom filters (issue 4752).
- Improved the Adblock Plus developer tools pane. Chrome’s dark theme is now supported (issue 4136), the Control-F search interface now works (issue 4644) and elements hidden by CSS property filters are now listed (issue 3596).
- Worked around a limitation with Chrome’s onCommitted event which caused many problems (issue 4598, 4599, 4647, 4804). Most notably this caused some requests to be improperly blocked / not blocked.
“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 22.214.171.1244.
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.
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.
The developer tools panel is now available in the development builds as of Adblock Plus 126.96.36.1993 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
ELEMHIDE, GENERICBLOCK and GENERICHIDE exception rules, that apply for any document on the current page. Note that if a
DOCUMENTexception rule applies, there won’t show any further items – as it pretty much disables Adblock Plus – for that document.