To prepare for better compatibility with AdGuard's own `set-constant`
scriptlet.
The 3rd position parameter which dictates how to set the value has
been converted into a vararg paramater, as follow:
..., as, function
..., as, callback
..., as, resolved
..., as, rejected
Similarly, the parameter used to dictate when the scriptlet
should become effective is now to be used as a vararg:
..., runAt, load
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/2783
Ideally, AdGuard would support its `stack` parameter as a
vararg, to be discussed.
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/2773
The `randomize` paramater introduced in https://github.com/gorhill/uBlock/commit/418087de9c
is now named `directive`, and beside the `true` value which is meant
to respond with a random 10-character string, it can now take the
following value:
war:[web_accessible_resource name]
In order to mock the XHR response with a web accessible resource. For
example:
piquark6046.github.io##+js(no-xhr-if, adsbygoogle.js, war:googlesyndication_adsbygoogle.js)
Will cause the XHR performed by the webpage to resolve to the content
of `/web_accessible_resources/googlesyndication_adsbygoogle.js`.
Should the resource not exist, the empty string will be returned.
Now support AdGuard's `randomize` parameter. If `true`,
the scriplet will generate a random 10-character string
to be returned as the response.
Reference:
https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#prevent-xhr
AdGuard's `prevent-xhr` also support `length:n-m` form,
but since I do not see it being used, for now it's not
supported in uBO's `no-xhr-if`.
Additionally, the scriptlet will now honor `responseType` and
return the proper response type accordingly.
`fetchPropsToMatch` is an optional variable argument. If provided,
the scriplet will take effect only when the JSON data is obtained
through `Response.json()` and if there is a match with the value of
`fetchPropsToMatch` and the properties of the `Response` instance.
Examples of usage:
...##+js(json-prune, ads, , , fetchPropsToMatch, ?param=)
...##+js(json-prune, ads, , , fetchPropsToMatch, url:?param= method:get)
The optional variable argument `fetchPropsToMatch` acts as an additional
narrowing condition to fulfill before the JSON data is pruned.
Specifically, the variable argument `log` can take one of three
values to enable logging mechanism:
..., log, match => log only when there is a match
..., log, nomatch => log only when there is no match
..., log, all => log unconditionally
Prepend pattern with `!` to test for unmatched patterns in
stack trace. This applies to sctiplet parameters which purpose
is to test against the stack, i.e. `aost` and `json-prune`.
Additionally, dropped support for JSON notation in favor of
optional variable arguments notation.
Related discussion:
- https://github.com/uBlockOrigin/uBlock-discussions/discussions/789#discussioncomment-6520330
This extends logging capabilities of `json-prune` scriptlet as
follow:
...##+js(json-prune, a, b, stackNeedle, log, [logneedle], logstack, 1)
Whereas before, the only way to log `json-prune` usage was to skip
providing the property chain:
...##+js(json-prune, , b)
Where `b` was the expression to filter out logging output.
With the extended logging capabilities, the logging output can
be filtered out with `logneedle`, which can be a regex literal.
Additionally, to log the stack trace the `stackNeedle` argument
must be set to non-empty string. You can use `/.^/` to log the
stack trace without matching it.
Raymond Hill