Please be careful when searching for ublock0 in the Chrome store. The real one (by gorhill) is listed below a third party one.
I always click the gorhill one, the others shown in the Chrome store I was wondering why they were even there (minus the new fork which I knew about) but went with what everyone was recommending in this topic.
Important: Please, do not ask me to publish to AMO or Chrome store. I am being very careful before publishing, and it may have already been done, but the submissions are pending review.
New:Ability to set the default state of per-site switches (issue #1193)
It is now possible to set the default value of per-site switches from the Settings pane in the dashboard, under the Default behavior header (see figure below). It was possible before to modify the default setting, but this had to be done by manually entering the proper rule in the My rules pane -- not very suitable to non-advanced users.
Primary purpose is to save bandwidth. See documentation for more information.
Note that this feature has been implemented with the utmost care to not add overhead to those not using it. The content scripts to handle interaction with blocked media elements are injected if and only if large media elements were actually blocked.
This release is mostly changes to comply with Opera store requirements -- a language translation must not be used if there is no corresponding description available.
Popup filters can also be used to filter popunders. This was the case in the original implementation of popunder filtering, however this was removed eventually as this was causing too many false positives for popunders, causing legitimate tabs to be closed (#1010). The new solution is to still filter popunders according to existing popup filters, but to disregard popup filters which are too broad. Cases for which a popunder cannot be taken care by an existing popup filter, an explicit popunder filter should be used.
From now on, uBlock Origin will pull assets (filter lists, scriptlets) from a project dedicated strictly for the purpose of maintaining those resources: uBlockOrigin/uAssets. Notice that this project is owned by uBlockOrigin, an organization I created to maintain all things related to uBlock Origin, uMatrix. For now uAssets is the first project to be held under that organization.
The goal of uBlockOrigin/uAssets is to receive all the reports for the need of new filters, or reports of web pages broken by existing filters, and will be open for people to contribute (i.e. given write permissions on the project). Ideally I wish there will be eventually a small army of volunteers dedicated to deal with filter issues.
It will now offer as filter choice background images, if any. (#1202)
When you click on an element on the page, it will report all elements found under the mouse.
Previously, the picker would report filters only for the element clicked and its ancestors.
Filters for media elements will now be offered, if any. (#1545)
You can now preview the effect of the selected filter on the page. (#650)
Chromium-based browsers
It is now possible to block websocket connections for Chromium-based browsers. (Chromium issue, #956, #1497):
Ability to filter websocket connections like any other network requests will take care of a new breed of ad-delivery techniques seen on more and more sites, and currently existing protocol-independent filters in filter lists will take care to filter out many of these websocket connections just like they did for http/https connections. For those wholesale-blocking 3rd parties on a site, websocket connections to 3rd-party servers will no longer escape the block.
Examples of cases solved by the ability to filter websocket connections with no need for special filters:
A general observation though, is that webscokets are more and more used: you will spot their use on sites such as GitHub, New York Times, etc.
Making uBO aware of websocket connections allows it to report these (previously invisible[1]) connections to the user, through the logger or through the dynamic filtering pane in the popup panel.
Emergency fix: removed WebSocket support for the time being (#1604):
I overestimated the number of people using the dev build of uBO -- and as a consequence assumed that any issue would have been reported prior to release.
I underestimated the use of WebSocket in the field -- turns out it's used way more than expected.
Sorry for the unexpected breakage.
Ideally, fixing the root issue would be best -- maybe starring the issue will make it more likely to be fixed sooner than later.
No significant change: I just tidied up changes made for the emergency fix released as 1.7.2. Now-unused code paths related to WebSocket wrapper code have been removed (they were bypassed in 1.7.2).
uBO was not suffering from the specific reported issue, but was theoretically suffering from the root cause at the source of incompatiblity between uMatrix and NoScript.
New cosmetic filtering operators: :has(), :xpath(), :style(). See detailed documentation at "Static filter syntax".
These new operators are to be used only for cosmetic filtering cases which are hard to crack -- more and more of these are surfacing (for example DOM elements with random class or id values).
When it comes to cosmetic filtering, preferably, always favor a plain old CSS3-based cosmetic filter, since they can be used in a declarative way, inside a style tag. But there are cases where no CSS3-based expression will work, and in such case consider these new :has and :xpath operators.
Note that unlike :has, :xpath is not a valid CSS4 expression, so they will always be enforced in a non-declarative way (in other word, javascript is doing the filtering, through document.evaluate).
These new cosmetic filtering operators can be "excepted" like any other standard CSS3-based cosmetic filter using the usual #@# prompt. Such exception cosmetic filters do not have to be specific however, i.e. you do not have to associate them to a specific hostname/entity.
Changes
The content script code responsible to implement cosmetic filtering has been re-factored:
To harden against sites which tries to work around uBO's cosmetic filtering.
To improve general performance and memory usage.
To support the new cosmetic filters.
Closed as fixed:
Firefox
uMatrix's fix to issue #540 has been imported into uBO.
Unspecified element removed: regression introduced in 1.8.0 when cosmetic filtering was refactored. Some classes of exception cosmetic filters were disregarded.
The issue is not specific to uBO, it likely affects any extension which implements shouldLoad().
The person who reported the bug would have found many other extensions being worst than uBO (including BluHell at 20s).
I could find a sensible work around for the shouldLoad() issue for uBO though, as explained in the bug comments.
Though the code change obviously benefits the specific test case in the bug report, it will lower the overhead uBO add to web pages in general in Firefox (e10s enabled or not).