Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/35#discussioncomment-11157444
New policy setting: `rulesets`
Type: array
Type of array items: string
Each item in the list is a list id (as seen in `rulesets/ruleset-details.json`),
prefixed with either `+` to enable the ruleset, or `-` to disable the ruleset.
Users will not be able to enable or disable rulesets present in the `rulesets`
policy. Disabled rulesets will not appear in the dashboard.
Use `-*` to remove all non-default rulesets, except for those added
using `+[ruleset_id]`.
Additionally, some work has been done to properly handle policy changes in
a non-blocking and deferred manner, as I observed that it often takes long
for calls to `storage.manage.get` to resolve. This potentailly takes care
of the following issue:
https://github.com/uBlockOrigin/uBOL-home/issues/174
See `managed_storage.json` for available settings. Currently
only `noFiltering` setting is availale.
`noFiltering` is an array of strings, each being a domain for
which no filtering should occur.
Related discussion:
- https://github.com/uBlockOrigin/uBOL-issues/discussions/35
Avoid using updateContentScripts() as it suffers from an unexpected
behavior, causing injected content scripts to lose proper order
at injection time. The order in which content scripts are injected
is key for uBOL content scripts. Potential out of order injection
was causing cosmetic filtering to be broken.
Use actual storage API to persist data across service worker
wake-ups and browser launches. uBOL was trying to avoid using
storage API, at the cost of somewhat hacky code (using DNR API
to persist settings).
Make use of session storage if available, to speed up
initialization of waking up the service worker (which at this
point is necessary to properly implement cosmetic filtering).
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.
Raymond Hill