uBlock Origin 1.10.5rc0

Changes:

Asset managements was refactored: details.

The user interface of the "3rd-party filters" has been revisited.

Procedural cosmetic filters can now be chained and recursive (something which was planned) . Examples:

• Chained: example.com##.item:matches-css-after(position: fixed):has-text(Promoted)
• Recursive: mobile.twitter.com##main [role="region"] > [role="grid"] > [role="rowgroup"] [role="row"]:if(div:last-of-type span:has-text(/^Promoted by/)) (actually a real use case).

There is no limit on the number of operators chained, or the number of recursion level, aside common sense. As a reminder, use procedural cosmetic filters only for when plain CSS selectors won't solve a case.

New procedural cosmetic filter operators:

• :has-text(argument): to filter elements according to whether they have a specific text string found in them. Use /.../ to match a literal regular expression instead of plain text.
• :if()/:if-not(argument): use to implement recursion, argument is itself a valid procedural cosmetic filter, but can also be a plain CSS selector.

Any of the operator which accept a text string value to match can also accept of literal regular expression value.

The :xpath() operator can now accept a plain CSS selector as prefix (i.e. example.com##.item:xpath(...)), just like all other operators. The XPath evaluation will use whatever element matches the CSS selector as the context node for the XPath.

The cost of parsing procedural cosmetic filters has been moved from content script-time to filter list compile-time, i.e. done only once when a filter list is updated.

The element picker supports all procedural cosmetic filters, i.e. it will also provide visual feedback as you enter manually such filters in the input field. Invalid filters, procedural or not, will be labelled with a bright red E.

Efficient procedural cosmetic filters (or any cosmetic filters really) are the ones which result in the smallest set of nodes to visit. The element picker input field will display the number of elements matching the current filter. The element picker will only consider the entered text up to the first line break, while leaving the rest as is. You can use this feature to break up your filter to find out the size of the resultset of the first part(s) of your filter: the smallest resultset the most efficient is your cosmetic filter.

Documentation about procedural cosmetic filters.

Closed as fixed

Firefox

• Chained unwanted popups not properly filtered

Firefox for Android

• Firefox Android configuration popup scrolling

Core

• Assets management refactored
• Not blocked websockets (worker)
• Want to create a regex to whitelist all google but no luck
• Ads are not blocked on bing.com web searches (issue filed for Edge, but also present on other platforms, those not supporting user styles or shadow DOM).
  • The fix needs to be tested/confirmed for the Edge version.
  • For Chromium-based browsers, use of shadow DOM has been removed in an attempt to simplify/unify generic implementation of the concept of user styles. (can be brought back if feedback shows it's needed).
  • Most reliable and low overhead cosmetic filtering is on modern Firefox (38+), all other platforms (Chromium, Edge, legacy Firefox, Safari) not providing proper "user styles" API rely on same generic implementation.
• Duplicate filter lists