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.
The ability to redirect xmlhttprequest to binary
resources was lost when redirectable/injectable
resources became immutable in commit
152cea2dfe.
This commit restores the ability to redirect a
xmlhttprequest to a binary resource by making
it possible to derive a data: URI from the
content of binary resources such as images.
Addtionally a redirect to a data: URI can be
forced by prefixing the resource token with `%`.
This is a non-official feature at this point,
i.e. it could be removed at any time.
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/310
The purpose of this new option is to add the ability
to create standalone redirect rule without being forced
to create a block filter (a corresponding block filter
is always created when using the `redirect=`).
Additionally:
The syntax `*$redirect=token,...` is now supported, there
is no need to "trick" the filter parser with
`*/*$redirect=token,...` in order to create redirect rules
which are meant to match all paths.
Filters of the form `|http*://` will be normalized into
two corresponding filters `|https://` and `|http://` so as
to reduce the number of filters in the buckets of
untokenizable filters.
Raymond Hill