Related bugzilla issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1736575
The issue was fixed months ago.
The removed code block is causing uBOL to be flagged as "including
remotely hosted code".
To be clear, the removed obsolete code block was not related to
executing remote code. The referenced code was in the file itself,
not remote, and this was a workaround for when Firefox was not
supporting injecting script in the `MAIN` world.
The issue was fixed months ago in Firefox, so there is no point for
the workaround.
When the target world of a scriptlet is the ISOLATED one,
skip Blob-based injection in Firefox, as the current world
is always the ISOLATED one. This should make ISOLATED
world-based scriptlets more reliable (i.e. execute sooner)
in Firefox.
Additionally:
Use `export UBO_VERSION=local` at the console to build MV3 extension using
current version of uBO code base. By default, the version is taken from
`./platform/mv3/ubo-version' and usually set to last stable release.
Related issues:
- https://github.com/uBlockOrigin/uBOL-issues/issues/5#issuecomment-1575425913
- https://github.com/w3c/webextensions/issues/403
Currently, there is no other way to inject CSS user styles than to
wake up the service worker, so that it can inject the CSS styles
itself using the `scripting.insertCSS()` method.
If ever the MV3 API supports injecting CSS user styles directly
from a content script, uBOL will be back to be fully declarative.
At this point the service worker is very lightweight since the
filtering is completely declarative, so this is not too much of
an issue performance-wise except for the fact that waking up the
service worker for the sole purpose of injecting CSS user styles
and nothing else introduces a pointless overhead.
Hopefully the MV3 API will mature to address such inefficiency.
Specifically, avoid long list of hostnames for the `matches`
property[1] when registering the content scripts, as this was causing
whole browser freeze for long seconds in Chromium-based browsers
(reason unknown).
The content scripts themselves will sort out which cosmetic filters to
apply on which websites.
This change makes it now possible to support annoyances-related lists,
and thus two lists have been added:
- EasyList -- Annoyances
- EasyList -- Cookies
Related issue:
- https://github.com/uBlockOrigin/uBOL-issues/issues/5
These annoyances-related lists contains many thousands of specific
cosmetic filters and as a result, before the above change this was
causing long seconds of whole browser freeze when simply modifying
the blocking mode of a specific site via the slider in the popup
panel.
It is now virtually instantaneous, at the cost of injecting larger
cosmetic filtering-related content scripts (which typically should
be garbage-collected within single-digit milliseconds).
Also, added support for entity-based cosmetic filters. (They were
previously discarded).
---
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/RegisteredContentScript
Source code of scriplets is now fetched directly from uBO
project, so there is no longer the need to keep duplicate
versions of scriplet code.
All scriplet filters are now supported.
This commit adds the ability to inject entity-based plain CSS
filters and also a set of the most commonly used entity-based
scriptlet injection filters.
Since the scripting API is not compatible with entity patterns,
the entity-related content scripts are injected in all documents
and the entity-matching is done by the content script themselves.
Given this, entity-based content scripts are enabled only when
working in the Complete filtering mode, there won't be any
entity-based filters injected in lower modes.
Also, since there is no way to reasonably have access to the
Public Suffix List in the content scripts, the entity-matching
algorithm is an approximation, though I expect false positives
to be rare (time will tell). In the event of such false
positive, simply falling back to Optimal mode will fix the
issue.
The following issues have been fixed at the same time:
Fixed the no-filtering mode related rules having lower priority
then redirect rules, i.e. redirect rules would still be applied
despite disabling all filtering on a site.
Fixed improper detection of changes to the generic-related CSS
content script, potentially causing undue delays when for example
trying to access the popup panel while working in Complete mode.
The scripting MV3 can be quite slow when registering/updating
large content scripts, so uBOL does its best to call the API only
if really needed, but there had been a regression in the recent
builds preventing uBO from properly detecting unchanged content
script parameters.
With the new csstree-based parser, it should now be
safe to parse `-abp-has` as declarative. There are over
a hundred such cosmetic filters in EasyList, and we want
to have these filters declaratively enforced whenever
possible in order to let the browser do the work natively
rather than rely on JS code.
The addition of those scriptlets will help uBOL to properly
filter more anti-blocker mechanisms on various site and also prevents
popups on many sites.
Also, fixed properly injecting scriptlets in embedded frames -- it
turns out I misunderstood the `allFrames` settings in the `scripting`
API.
Fixed trusted sites not being excluded from declarative
scripting.
Assign "uBOL_"-prefixed name to anonymous scripting functions
so that they can be easily found in performance profiler results
in dev tools.
Imrpove spread of chunks of filters across declarative scripting
files.
This solves the following remaining issues regarding specific cosmetic
filtering:
- High rate of false positives in last build
- High number of generated content css files in the package
First iteration of adding scriptlet support. As with cosmetic
filtering, scriptlet niijection occurs only on sites for which
uBO Lite was granted extended permissions.
At the moment, only three scriptlets are supported:
- abort-current-script
- json-prune
- set-constant
More will be added in the future.
Raymond Hill