1.10.5rc1

@gorhill gorhill released this Jan 24, 2017

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

Firefox for Android

Core

Downloads

1.10.2

@gorhill gorhill released this Dec 14, 2016 · 67 commits to master since this release

Changes

Cosmetic filtering

Implementation of cosmetic filter operator :matches-css has been revised according to the discussion at #1930 (comment) and request in uBlockOrigin/uAssets#212:

  • :matches-css now accept no more than one single style property. If more than one style property must be matched on the same node, you will need to chain them (i.e. div##matches-css(...):matches-css(...) -- ability to chain is coming for next release). Since there is only one style property, do not use trailing ;.
  • :matches-css-before() and :matches-css-after() are now also available to specifically match style property for the pseudo elements :before and :after on a node.
  • Support the use of regexes for property matching: if the first and last character of the value to match is /, the value will be deemed to be a literal regular expression which must be matched.

Dashboard

The last dashboard's pane you visited will be automatically opened next time you open the dashboard (issue #2206).


Closed as fixed:

Edge

Firefox

Core

Downloads

1.10.1rc1

@gorhill gorhill released this Dec 8, 2016 · 71 commits to master since this release

Changes

Cosmetic filtering

Implementation of cosmetic filter operator :matches-css has been revised according to the discussion at #1930 (comment) and request in uBlockOrigin/uAssets#212:

  • :matches-css now accept no more than one single style property. If more than one style property must be matched on the same node, you will need to chain them (i.e. div##matches-css(...):matches-css(...) -- ability to chain is coming for next release). Since there is only one style property, do not use trailing ;.
  • :matches-css-before() and :matches-css-after() are now also available to specifically match style property for the pseudo elements :before and :after on a node.
  • Support the use of regexes for property matching: if the first and last character of the value to match is /, the value will be deemed to be a literal regular expression which must be matched.

Dashboard

The last dashboard's pane you visited will be automatically opened next time you open the dashboard (issue #2206).


Closed as fixed:

Edge

Firefox

Core

Downloads

1.10.0

@gorhill gorhill released this Nov 28, 2016 · 91 commits to master since this release

Changes

Dynamic filtering pane

The dynamic filtering pane in the popup panel is now available in read-only mode to users who did not enable "I am an advanced user" in Settings:

Dynamic filtering pane in read-only mode

The rationale for this change is explained in issue 2010. It still is collapsed by default, but can be brought up by clicking the "requests blocked" or "domains connected" fields in the main area.

Template-based scriptlets

In order to promote the reuse of injectable scriplets across different sites, it is now possible for a scriptlet to accept arguments. The arguments are comma-separated and appear after the token, for example (a real case):

golem.de##script:inject(abort-on-property-write.js, _sp_)

In the example above, the scriplet abort-on-property-write.js contains a placeholder for one argument, which placeholder will be replaced with the argument _sp_. Placeholders for scriplets which accept arguments will always be for string values (reminder that injectable scriplets are part of the project, never from an external party).

Advanced settings

A new "Advanced settings" pane, available only to advanced users. It contains settings which are experimental, or which are of interest to advanced users who want more control over how uBO behaves internally. I do not want to bloat the Settings pane in the dashboard with settings which are of interest only to a minority of users or which are experimental: this is where the new "Advanced settings" pane is useful.

When you enabled "Advanced users" in the Settings pane, a cogs icon will appear next to that setting. Click this cogs icon to access those "hidden" advanced settings:

the cogs icon

The UI of the advanced settings page is purposefully stern. Keep in mind that whatever settings you see in there may be experimental and could be removed at any time in the future.

Experimental advanced setting of interest: suspendTabsUntilReady (default to false), to prevent uBO from establishing any remote connection at launch before all filter lists/settings have been fully loaded (related issue #1327). How well it works will have to be evaluated by users.

WebExtensions

From now on, there will be a Firefox's WebExtension version of uBO (see uBlock0.webext.zip below, see "Temporary Installation in Firefox" on how to install on Firefox). Do not bother trying it out if you do not have Nightly 52.0a1 (2016-10-29) or later installed. Also, do not open issues here for the WebExtension version of uBO -- it is still at an experimental stage and there are things which are known to be missing in the API for uBO to fully function: see bugzilla 13099260.


Closed as fixed:

Firefox:

Core

Downloads

1.9.16

@gorhill gorhill released this Oct 24, 2016 · 158 commits to master since this release

Changes:

Some work has been done on the element picker:

  • can now handle procedural cosmetic filters (:has, matches-css, :xpath), and also the special operator :style -- matching elements of such filters will be highlighted like normal CSS selector-based filters.
  • an invalid filter in the input field will now trigger a visual cue: the background of the input field will be reddish.
  • the number of elements on the current page matching the filter in the input field is now displayed in the bottom right corner of the input field.
  • the preview mode is now sticky, i.e. you can modify the filter in the input field without being kicked out of preview mode. Convenient when creating :style-based cosmetic filters.

The Privacy setting "Disable hyperlink auditing/beacon" has been changed to "Disable hyperlink auditing", and network requests of type beacon are no longer blanket-blocked. The network requests of type beacon will now be filtered just like any other network requests, according to the current filters/rules. [need to update wiki doc].

Network requests of type csp_report will be blocked regardless of filters/rules when there is a probability they are fired as a result of uBO internally redirecting one or more network requests to neutered resources. In such case, uBO considers these csp_report network requests as "spurious" and blocks them. An example of such spurious CSP reports being fired as a result of uBO redirecting resources is https://medium.com/ (see dev console when loading a page from that site), where a CSP report is fired by the browser as a result of uBO redirecting Google Analytics script to uBO's neutered version.

Closed as fixed:

Chromium

Core

Downloads

1.9.14

@gorhill gorhill released this Oct 5, 2016 · 205 commits to master since this release

This version is worth publishing only for Opera store currently -- as neither Chromium nor Chrome expose the specific setting which uBO was overwriting.

Closed as fixed:

Chromium

Downloads

1.9.12

@gorhill gorhill released this Oct 2, 2016 · 205 commits to master since this release

Closed as fixed:

Firefox

Downloads

1.9.8

@gorhill gorhill released this Sep 21, 2016 · 225 commits to master since this release

Changes

Core code related to static and cosmetic engines has been refactored to take advantage of ES6 Set/Map (related issue: #1070). Polyfilled versions of Set/Map are provided for compatibility with Chromium 37 and less[1], and for Pale Moon 26 and earlier[2]. While at it, I also revisited some of the inner-most loops executed at load time to remove other observed overheads in profiling results.

Benchmarks shows that there are good gains to be had in performance and memory efficiency when using ES6 Set/Map. The performance gains are especially true when dealing with collections with a lot of misses, which is typical of the static and cosmetic filtering engines ni uBO.

Following the above refactoring, profiling Chromium/Firefox, I observed:

  • Non-selfie case: uBO will roughly load in about half the time, because:
    • Using ES6 Set and Map instead of Object
    • No longer using String.split to split lines into fields = less memory allocations = less work for garbage collector
  • Selfie-case: there is a marginal performance improvement at most in boot time -- make sense since a selfie is just a no-parsing-at-all load mechanism regardless of how the data is represented internally.

Chromium + uBO with default settings + EasyList Germany -- forgot to un-check it before profiling...
a

Nightly + uBO with default settings
a

Closed as fixed:

Chromium

Core


  1. When the polyfilled Set/Map are used for Chromium-based browsers, uBO's memory usage will be higher, as using Object as Set or Map is less efficient memory-wise (though still fast).
  2. For Pale Moon 26 and less, Set/Map iterators are not ES6-compatible.

Downloads