This also apply to setInterval-if. Thus to defuse
calls to setTimeout(fn, 1000), the filter could be:
##+js(stif, , !1000)
Meaning "allow setTimeout if the delay is not 1000".
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/
Usage is similar to that of raf-if introduced in
commit 6831967f5f.
The two new scriptlets are meant to replace:
- setTimeout-defuser
- setTimeout-logger
- setInterval-defuser
- setInterval-logger
setTimeout-logger and setInterval-logger have been
removed, since they are not to be used in production.
To log setTimeout and setInterval usage, respectively
(using aliases):
- ##+js(stif)
- ##+js(siif)
To defuse setTimeout unconditionally:
- ##+js(stif, !)
Usage of setTimeout-defuser and setInterval-defuser
is deprecated and will be removed in some future when
they are no longer in use.
Keep in mind that the new scriptlets function on a
whitelist basis, whereas the deprecated ones
function on a blacklist basis. Prefixing the needle
with `!` allow to use the new scriptlets on a
blacklist basis.
Scriptlet name: `raf-if.js`
Usage: `example.com##+js(raf-if, !/(\d+){4}/)`
Argument: one single argument, which is the "needle" to
find in the stringified argument passed to
requestAnimationFrame.
requestAnimationFrame will be defused when:
- The needle is not prefixed with `!` and the needle
does not match the stringified argument; OR
- The needle is prefixed with `!` and the needle
matches the stringified argument.
The `raf-if.js` scriptlet will log calls to
requestAnimationFrame to the console when no parameter
is provided, i.e.:
example.com##+js(raf-if)
Otherwise no logging occurs.
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.
