uBO will now verify that at least one unprocessed network requests
at launch should have been blocked in order to warn users of
unprocessed network requests through the `!` toolbar icon badge.
For example, with default filter lists, there is nothing to block
on `wikipedia.org`, and hence in this case it's not useful to
present the user with the `!` badge.
Therefore uBO will not show the badge *only* when at least one
unprocessed network requests should have been blocked had uBO been
ready when it was fired by the browser.
Related commit:
- https://github.com/gorhill/uBlock/commit/769b8da664be
Emergency update of assets could be repeatedly launched
every 15 seconds if a resource could not be fetched from
a server. A cooldown period has been added to prevent
repeatedly launching emergency updates.
Before this commit, a network error condition was not reported
when the filter list was imported, it was only reported afterward
when the imported filter list was updated.
Caused by the fact that external filter lists do not have an
`off` property even when they are not enabled.
Additionally, set the default update cycle check period to 2hr.
The scriptlet addEventListenerLogger has been removed.
The logging of addEventListener() calls can now be done with the
addEventListenerDefuser scriptlet, which now supports the
following named arguments:
"type": the event type to match. Default to '', i.e. match-all.
"pattern": the pattern to match against the handler argument
Default to '', i.e. match-all.
"log": an integer value telling when to log:
- 1: log only when both type and pattern matches, i.e. when a
call to addEventListener() is defused
- 2: log when either the type or pattern matches
- 3: log all calls to addEventListener()
"debug": an integer value telling when to break into the
debugger, useful to inspect the debugger's call stack.
- 1: break into the debugger when both type and pattern match,
so effectively when defusing is taking place.
- 2: break into the debugger when either type or pattern matches.
The usage of named arguments is optional, positional arguments
are still supported as documented. Named arguments is required
to use "log" and/or "debug" arguments.
Obviously, do not use "log" or "debug" in any filter list, these
are investigative tools for filter list authors.
Examples of usage using named arguments:
wikipedia.org##+js(aeld, { "type": "/mouse/", "pattern": "/.^/", "log": 2 })
Above filter will log calls to addEventListener() which have the
pattern "mouse" in the event type (so "mouseover", "mouseout",
etc.) without defusing any of them (because pattern can't match
anything).
wikipedia.org##+js(aeld, { "type": "/.^/", "log": 2 })
Above filter will log all calls without defusing any of them
(because type can't match anything)
wikipedia.org##+js(aeld, { "log": 1 })
Above filter will log and defuse all calls to addEventListener().
Builtin scriptlets are no longer parsed as text-based resources,
they are imported as JS functions, and `toString()` is used to
obtain text-based representation of a scriptlet.
Scriptlet parameters are now passed as function call arguments
rather than by replacing text-based occurrences of `{{i}}`. The
arguments are always string values (see below for exception).
Support for argument as Object has been added. This opens the
door to have scriptlets using named arguments rather than
positional arguments, and hence easier to extend functionality
of existing scriptlets. Example:
example.com##+js(scriplet, { "prop": "adblock", "value": false, "log": true })
Compatibility with user-provided scriptlets has been preserved.
User-provided scriptlets can benefit some of the changes:
Use the form `function(..){..}` instead of `(function(..){..})();`
in order to received scriptlet arguments as part of function call
-- instead of using `{{i}}`.
If using the form `function(..){..}`, you can choose to receive
an Object as argument -- just be sure that your scriptlet's
parameter is valid JSON notation.
Raymond Hill