... from platform-independent code.
This should complete the de-chromiumification of
uBO. Next step will be to swap the content of the
`platform/chromium` and `platform/firefox`
folders so as to reflect that Firefox is the
natural platform for uBO.
Related documentation:
- https://help.eyeo.com/en/adblockplus/how-to-write-filters#element-hiding
Related feedback/discussion:
- https://www.reddit.com/r/uBlockOrigin/comments/d6vxzj/
The `elemhide` filter option as per ABP semantic is
now supported. Previously uBO would consider `elemhide`
to be an alias of `generichide`.
The support of `elemhide` is through the convenient
conversion of `elemhide` option into existing
`generichide` option and new `specifichide` option.
The purpose of the new `specifichide` filter option
is to disable all specific cosmetic filters, i.e.
those who target a specific site.
Additionally, for convenience purpose, the filter
options `generichide`, `specifichide` and `elemhide`
can be aliased using the shorter forms `ghide`,
`shide` and `ehide` respectively.
Little-used code from vapi-client.js has been moved
to vapi-client-extra.js. Given that vapi-client.js
is injected in all web pages, this means less dead
code being injected in all pages.
Swathes of code in vapi-client.js was used only in
a few very specific cases, such as when the logger's
DOM inspector is opened or when the "Filter lists"
pane in the dashboard is opened -- and thus to avoid
that little used code to be loaded in every web page
unconditionally, it has been moved to its own
separate file, vapi-client.extra.js.
vapi-client-extra.js is loaded declaratively or
programmatically only where needed.
No need to store mouse coordinates in background
page, thus no need to post mouse coordinates
information for every click.
Rename/group element picker arguments and popup
arguments separately.
Reported by:
- https://github.com/uBlock-user:
Imported custom list were incorrectly seen as out of
date immediately after import operation.
Regression from:
- e27328f931
A few lines of code were improperly removed during
refactoring.
Also, coallesce calls to selfieManager.destroy() so as
to avoid undue repeated calls to storage deletion of
selfie assets.
Related commit:
- e27328f931
Related commit:
- e27328f931
The regression was preventing the compiled filter
lists from being properly loaded by uBO, thus
always causing a full parsing/compiling at
launch time.
Issue reported by @uBlock-user in team channel.
Creating cosmetic procedural exception filters was
causing `cosmetic-logger.js` scriptlet to throw at
and thus further breaking the logging of cosmetic
filters overall.
Reuse permanent instances instead. The trailing `$` is
used to denote these variables are register-like
instances, i.e. their content is valid only for the
duration of the call. (From now on I will use this
convention throughout the code base.)
Entity-based filters where not properly looked-up if
they used subdomains. Example:
- `example.*##^script` => ok
- `www.example.*##^script` => failed on `https://www.example.com/`
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/710
Messages from unprivileged ports (i.e. from content scripts)
are no longer relayed to message handlers which are to be
strictly used to execute privileged code.
The last remaining case of unprivileged messages which
should be converted into a privileged ones will be taken
care of when the following issue is fixed:
- https://github.com/gorhill/uBlock/issues/3497
Related commit:
- fb4e94f92c
A bidi-trie can't store strings longer than 255 characters
because the string segment lengths are encoded into a single
byte. This commit ensures only strings smaller than
256 characters are stored in the bidi-tries.
Plain filters can be any length, while the bidi-trie was
assuming max length of 256. The origin of this error
is from when the bidi-trie code was originally imported
from the hntrie code as start to develop bidi-trie.
The erroneous code could cause issue when the following
conditions were met:
- Plain filter longer than 256 characters
- Free space in bidi-trie's character buffer was less
than 256 bytes
Likely a rare occurrence, but some filter lists do contains
long plain filters, for example:
https://gitlab.com/curben/urlhaus-filter/raw/master/urlhaus-filter.txt
Related feedback:
- https://www.reddit.com/r/uBlockOrigin/comments/cs1y26/
The purpose is to wholly disable scriptlet injection
for a given site without having to create exceptions
for all matching scriptlet injection filters.
The following exception filter will cause scriptlet
injection to be wholly disable for `example.com`:
`example.com#@#+js()`
Or to disable scriptlet injection everywhere:
`#@#+js()`
The following form is meaningless and will be
ignored:
`example.com##+js()`
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/701
The filter option `empty` is converted to `redirect=empty`
by uBO internally; however unlike when the `redirect=`
option is used expressly, the `empty` option does not
require a resource type.
When `empty` is used, only network requests which are meant
to return a text response will be redirected to an empty
response body by uBO -- so `empty` will not work for
resources such as images, media, or other binary resources.
Related commit & feedback:
- 7ff750eaf6
The color value for the icon badge is now
"attached" to the blocking profile value.
Additionally, as per feedback, `3p` rules
will be relaxing before master JavaScript
switch rules.
Related feedback:
- https://www.reddit.com/r/uBlockOrigin/comments/cmh910/
Additionally, the `3p` rule has been made distinct from
`3p-script`/`3p-frame` for the purpose of
"Relax blocking mode" command.
The badge color will hint at the current blocking mode.
There are four colors for the four following blocking
modes:
- JavaScript wholly disabled
- All 3rd parties blocked
- 3rd-party scripts and frames blocked
- None of the above
The default badge color will be used when JavaScript is not
wholly disabled and when there are no rules for `3p`,
`3p-script` or `3p-frame`.
A new advanced setting has been added to let the user choose
the badge colors for the various blocking modes,
`blockingProfileColors`. The value *must* be a sequence of
4 valid CSS color values that match 6 hexadecimal digits
prefixed with`#` -- anything else will be ignored.
