Potentially breaking change:
`urlskip=` option will no longer apply by default to blocked network
requests, only network requests which are not blocked can be skipped
through a `urlskip=` filter.
The new `urlskip=` directive `-blocked` can be used to explicitly
allow a `urlskip=` filter to also apply to blocked network requests.
Example: given the filter `||example.com^`, the filter:
||example.com/path/to/tracker$urlskip=?url
Will not prevent strict-blocking when navigating to:
https://example.com/path/to/tracker?url=https://example.org/
However, the filter:
||example.com/path/to/tracker$urlskip=-blocked ?url
Will cause the strict-blocking to be ignored and allow navigation
to proceed to the URL extracted as a result of applying the `urlskip=`
filter:
https://example.org/
Related discussion:
https://github.com/uBlockOrigin/uBlock-issues/issues/3206#issuecomment-2439627386
Related feedback:
https://github.com/uBlockOrigin/uBlock-issues/issues/3206#issuecomment-2403795984
The first capture group of the regex will be used as the result of the
transformation. Example:
||podtrac.com/pts/redirect.mp3/$urlskip=/podtrac\.com\/pts\/redirect\.mp3\/(.*?\.mp3\b)/ +https
If the regex is invalid, or if it fails to extract a first capture
group, no redirection will occur.
A single request can require multiple calls to the static network
filtering engine (SNFE). The reported timing is the result of
going through *all* the required calls to SNFE. In effect, a
single call to SNFE.match() is a fraction of the reported timing.
BroadcastChannel constructor throws in Firefox when Enhanced
Tracking Protection is set to "strict".
This behavior could cause scriptlet injection to wholly break
when uBO's logger was opened, as BroadcastChannel() is used
by scriptlets to report information to the logger.
This commit ensures that exceptions from BroadcastChannel
constructor are properly handled.
The scriptlets will fall back to report at the console should
they be unable to report to the logger through BroadcastChannel.
Ensure serialization returns copy of data rather than live
references to data. This allows to immediately deserialize() the
result of serialize().
Also, adjust code to modified behavior of filterQuery().
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/3394
When the "No large media elements" per-site switch is toggled on,
it will also act to prevent autoplay of video/audio media, regardless
of their size. This also works for xhr-based media streaming.
If blocking by size is not desirable while blocking autoplay is
desired, one can toggle on "No large media elements" switch while
setting "Block media elements larger than ..." to a very high value.
Default to `true`.
Set to `false` to wholly disable calls to `dns.resolve()` (Firefox-
only). Disabling calls to `dns.resolve()` will prevent cname-uncloaking
and will limit ability to enforce `ipaddress` filter option.
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/3206
The main purpose is to bypass URLs designed to track whether a user
visited a specific URL, typically used in click-tracking links.
The `urlskip=` option ...
- ... is valid only when used in a trusted filter list
- ... is enforced only on top documents
- ... is enforced on both blocked and non-blocked documents
- ... is a modifier, i.e. it cannot be used along with other
modifier options in a single filter
The syntax is `urlskip=[steps]`, where steps is a space-separated
list of extraction directives detailing what action to perform on
the current URL.
The only supported directive in this first commit is `?name`,
which purpose is to extract the value of a named URL parameter
and use the result as the new URL. Example:
||example.com/path/to/tracker$urlskip=?url
The above filter will cause navigation to
https://example.com/path/to/tracker?url=https://example.org/
to automatically bypass navigation to `example.com` and navigate
directly to
https://example.org/
It is possible to recursively extract URL parameters by using
more than one directive, example:
||example.com/path/to/tracker$urlskip=?url ?to
More extraction capabilities may be added in the future.
DNR conversion module is a dev tool, no point loading it by
default. This was done this way because in a distant past uBO
had to be compatible with browsers not supporting dynamically
loaded modules.
Currently all supported browser versions support dynamically
loaded modules.
In Firefox-specific contentScripts API used to register
scriptlets. This could potentially occurs when there are
registrations pending during a reload of filter lists.
This commit makes the DNS resolution code better suited for both
filtering on cname and ip address. The change allows early availability
of ip address so that `ipaddress=` option can be matched at
onBeforeRequest time.
As a result, it is now possible to block root document using
`ipaddress=` option -- so long as an ip address can be extracted
before first onBeforeRequest() call.
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/2792
Caveat
------
the ip address used is the first one among the list of ip
addresses returned by dns.resolve() method. There is no way for uBO
to know which exact ip address will be used by the browser when
sending the request, so this is at most a best guess. The exact IP
address used by the browser is available at onHeadersReceived time,
and uBO will also filter according to this value, but by then the
network request has already been sent to the remote server.
Possibly a future improvement would make available the whole list
of ip addresses to the filtering engine, but even then it's impossible
to know with certainty which ip address will ultimately be used by the
browser -- it is entirely possible that the ip address used by the
browser might not be in the list received through dns.resolve().
If an IP address can be extracted from the hostname portion of
a URL, the IP address matching will be performed at onBeforeRequest()
time.
Regardless, IP address matching will subsequently always be performed
at onHeadersReceived() time as the request details at that point
contain a reliable IP address value on supported platforms (Firefox-
only as of now).
The `cap_ipaddress` now evaluates to `true` in Chromium-based
browsers. Even though these browsers are unable to provide reliable
IP address value at onHeadersReceived() time, they can still
perform IP address matching for IP address extracted from hostname
portion of a URL.
