Also added additional safeguard against sticky unprocessed-request
status: all unprocessed-request statuses will be cleared after a
minute elapsed following intialization. The idea is that if the
user hasn't care to force a reload of the page, then it's assumed
to be by choice and uBO should stop informing about the status.
What does not work at the time of commit:
Cosmetic filtering does not work:
The content scripts responsible for cosmetic filtering fail when
trying to inject the stylesheets through document.adoptedStyleSheets,
with the following error message:
XrayWrapper denied access to property Symbol.iterator
(reason: object is not safely Xrayable).
See https://developer.mozilla.org/en-US/docs/Xray_vision for more
information. ... css-declarative.js:106:8
A possible solution is to inject those content scripts in the
MAIN world. However Firefox scripting API does not support MAIN
world injection at the moment.
Scriptlet-filtering does not work:
Because scriptlet code needs to be injected in the MAIN world,
and this is currently not supported by Firefox's scripting API,
see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575
There is no count badge on the toolbar icon in Firefox, as it
currently does not support the `DNR.setExtensionActionOptions`
method.
Other than the above issues, it does appear uBO is blocking
properly with no error reported in the dev console.
The adoptedStyleSheets issue though is worrisome, as the
cosmetic filtering content scripts were designed with ISOLATED
world injection in mind. Being forced to inject in MAIN world
(when available) make things a bit more complicated as uBO
has to ensure it's global variables do not leak into the page.
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
Related feedback:
- 769b8da664 (commitcomment-104695781)
The incomplete filtering status of a given tab at browser launch
will be carried over visually as a yellowish `!` badge until the
web page in the tab is force reloaded, navigated away, or closed.
The purpose is to make it obvious to end users that a web page
has not been filtered properly and to avoid issue reports
related to this.
It is expected that Firefox should never be affected by cases of
yellowish badge -- that is unless the setting "Suspend network
activity [...]" has been disabled, in which case the new behavior
will also be useful to those who disabled the setting.
Related discussion:
- https://github.com/uBlockOrigin/uAssets/discussions/16939
Until uBO's filtering engines are properly initialized, there will
be a distinct toolbar icon to help users understand that uBO may
not be fully initialized when a webpage is loaded -- often the
cause of improper filtering of trackers/ads at browser launch.
Raymond Hill