Bring latest changes to procedural cosmetic filtering to uBOL.
Fix procedural filtering used in HTML filters.
Standardize quick hash algorithm used throughout to DJB2
(except that initialization step is skipped):
- http://www.cse.yorku.ca/~oz/hash.html#djb2
These two new pseudo selectors are _action_ operators, and thus can
only be used at the end of a selector. They both take as argument
a string or regex literal.
For `:remove-class()`, when the argument matches a class name, that
class name is removed.
For `:remove-attr()`, when the argument matches an attribute name,
that attribute is removed.
These operators are meant to replace `+js(remove-attr, ...)` and
`+js(remove-class, ...)`, which from now on are candidate for
deprecation in some future.
Once the next stable release is widespread, filter authors must use
these two new operators instead of their `+js()` counterparts.
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2329
The supported syntax is exactly as per AdGuard's documentation:
- https://kb.adguard.com/en/general/how-to-create-your-own-ad-filters#extended-css-matches-attr
Though recommended, the quotes are not mandatory in uBO if
the argument does not cause the parser to fail and if there
are no ambiguities.
Additionally, improved the code to better unquote pseudo-operator
arguments, and to bring it closer to how AdGuard does it as per
documentation. When using quotes, `"` and `\` should be escaped
to preserve these characters in the unquoted version of the
argument.
Additionally, it is now possible to have `:has-text()` match the
empty string by just quoting the empty string:
...##foo:has-text("")
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2292
This will prevent unexpected oversezealous blocking if ever
this happens again. The internal void operator will ensure
no blocking takes place and issue a note about non-existing
operator to the dev tools console.
The new parser no longer uses the browser DOM to validate
that a cosmetic filter is valid or not, this is now done
through a JS library, CSSTree.
This means filter list authors will have to be more careful
to ensure that a cosmetic filter is really valid, as there is
no more guarantee that a cosmetic filter which works for a
given browser/version will still work properly on another
browser, or different version of the same browser.
This change has become necessary because of many reasons,
one of them being the flakiness of the previous parser as
exposed by many issues lately:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2262
- https://github.com/uBlockOrigin/uBlock-issues/issues/2228
The new parser introduces breaking changes, there was no way
to do otherwise. Some current procedural cosmetic filters will
be shown as invalid with this change. This occurs because the
CSSTree library gets confused with some syntax which was
previously allowed by the previous parser because it was more
permissive.
Mainly the issue is with the arguments passed to some procedural
cosmetic filters, and these issues can be solved as follow:
Use quotes around the argument. You can use either single or
double-quotes, whichever is most convenient. If your argument
contains a single quote, use double-quotes, and vice versa.
Additionally, try to escape a quote inside an argument using
backslash. THis may work, but if not, use quotes around the
argument.
When the parser encounter quotes around an argument, it will
discard them before trying to process the argument, same with
escaped quotes inside the argument. Examples:
Breakage:
...##^script:has-text(toscr')
Fix:
...##^script:has-text(toscr\')
Breakage:
...##:xpath(//*[contains(text(),"VPN")]):upward(2)
Fix:
...##:xpath('//*[contains(text(),"VPN")]'):upward(2)
There are not many filters which break in the default set of
filter lists, so this should be workable for default lists.
Unfortunately those fixes will break the filter for previous
versions of uBO since these to not deal with quoted argument.
In such case, it may be necessary to keep the previous filter,
which will be discarded as broken on newer version of uBO.
THis was a necessary change as the old parser was becoming
more and more flaky after being constantly patched for new
cases arising, The new parser should be far more robust and
stay robist through expanding procedural cosmetic filter
syntax.
Additionally, in the MV3 version, filters are pre-compiled
using a Nodejs script, i.e. outside the browser, so validating
cosmetic filters using a live DOM no longer made sense.
This new parser will have to be tested throughly before stable
release.
This commit deprecates matches-css-before() and matches-css-after(): these
should no longer be used once 1.45.0 is published and widespread. The
deprecated syntax will eventually be removed in some future.
The syntax of procedural operator matches-css() has been extended to also
be able to target pesudo elements. Examples:
Same as before:
example.com##p:matches-css(opacity: 0.5)
This is the new way to target an `::after` pseudo-element:
example.com##p:matches-css(after, content: Ads)
This is the new way to target a `::before` pseudo-element:
example.com##p:matches-css(before, content: Ads)
The new syntax also means any valid pseudo-element can now be used as
a target:
example.com##p:matches-css(first-letter, opacity: 0.5)
If the first argument does not match the pattern "property name: value",
then it will be deemed a pseudo-element to target, and the second argument
will be the "property name: value".
Related issue:
- https://github.com/AdguardTeam/ExtendedCss/issues/150
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2185
The argument must be a valid media query as documented on MDN, i.e.
what appears between the `@media` at-rule and the first opening
curly bracket (including the parentheses when required):
- https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries
Best practice:
Use `:matches-media()` after plain CSS selectors, if any.
Good:
example.com###target-1 > .target-2:matches-media((min-width: 800px))
Bad (though this will still work):
example.com##:matches-media((min-width: 800px)) #target-1 > .target-2
The reason for this is to keep the door open for a future optimisation
where uBO could convert `:matches-media()`-based filters into CSS media
rules injected declaratively in a user stylesheet.
The purpose of this new procedural operator is to target
all elements _outside_ than the currently selected set of
elements.
For any element feeding into `others()`, the resultset
of the `others()` operator will include everything else
except:
- the descendants of a subject element
- the ancestors of a subject element
The resultset will contains the siblings of a subject
element _except_ when those siblings are either a
descendant or ancestor of another subject element.
Related discussion:
- https://www.reddit.com/r/uBlockOrigin/comments/slyjzp/
Though this operator is unlikely to be used in default lists,
it opens the door to create specialized filter lists which
purpose is some sort of "reader mode", where everything
_else_ than a selected set of elements are hidden from view.
Examples of usage:
twitter.com##:matches-path(/^/home/) [data-testid="primaryColumn"]:others()
nature.com##:matches-path(/^/articles//) :is(.c-breadcrumbs,.c-article-main-column):others()
The status is currently considered experimental and support
might be removed in the future if it turns out there is no
sufficient usage or if unforeseen difficult issues arise
implementation-wise.
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1690
New procedural operator: `:matches-path(...)`
Description: this is a all-or-nothing passthrough operator, which
on/off behavior is dictated by whether the argument match the
path of the current location. The argument can be either plain
text to be found at any position in the path, or a literal regex
against which the path is tested.
Whereas cosmetic filters can be made specific to whole domain,
the new `:matches-path()` operator allows to further narrow
the specificity according to the path of the current document
lcoation.
Typically this procedural operator is used as first operator in
a procedural cosmetic filter, so as to ensure that no further
matching work is performed should there be no match against the
current path of the current document location.
Example of usage:
example.com##:matches-path(/shop) p
Will hide all `p` elements when visiting `https://example.com/shop/stuff`,
but not when visiting `https://example.com/` or any other page
on `example.com` which has no instance of `/shop` in the path part
of the URL.
The procedural cosmetic filtering code has been split from
the content script code injected unconditionally and will
from now on be injected only when it is needed, i.e. when
there are procedural cosmetic filters to enforce.
The motivation for this is:
https://www.debugbear.com/blog/2020-chrome-extension-performance-report#what-can-extension-developers-do-to-keep-their-extensions-fast
Though uBO's content script injected unconditionally in all
pages/frames is relatively small, I still wanted to further
reduce the amount of content script code injected
unconditionally: The procedural cosmetic filtering code
represents roughly 14KB of code the browser won't have to
parse/execute unconditionally unless there exists procedural
cosmetic filters to enforce for a page or frame.
At the time the above article was published, the total
size of unconditional content scripts injected by uBO was
~101 KB, while after this commit, the total size will be
~57 KB (keeping in mind uBO does not minify and does not
remove comments from its JavaScript code).
Additionally, some refactoring on how user stylesheets are
injected so as to ensure that `:style`-based procedural
filters which are essentially declarative are injected
earlier along with plain, non-procedural cosmetic filters.
