Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/214
This implements basic functionality for strict blocking, i.e. the
ability to block navigation to undesirable websites. This is a
first implementation, which converts only filters that are plain
hostnames.
Unlike with uBO, it is not possible to know from which ruleset a
blocking rule originates. Nonetheless, users will have to make a
choice as to whether navigation should proceed or not.
A setting has been added to the dashboard to wholly enable/disable
strict blocking. It is enabled by default.
Potential future improvements, pending investigation on feasability
in an MV3 framework:
- Extend coverage to explicit `document` filters
- Leverage and use `urlskip=` filters in the blocking page in order
to proceed while bypassing unwanted redirects.
New managed setting:
"disabledFeatures": {
"title": "User interface features to disable",
"description": "A list of tokens, each of which correspond to a user interface feature to disable.",
"type": "array",
"items": { "type": "string" }
}
Supported tokens:
- `dashboard`: Prevent access to all dashboard settings
- `filteringMode`: Prevent changes to the default filtering mode,
or the current filtering mode of any site
Related feedback:
https://github.com/uBlockOrigin/uBOL-home/discussions/35#discussioncomment-11326086
Collecting matched rules when the extension is side-loaded is now
opt-in, by enabling "Developer mode" in the dashboard.
The reason is to allow the extension to behave same as the official
released version when side-loaded.
Specifically, as side-loaded extension, uBOL's service worker would
wake up due to matched-rule listener even though it would not wake
up the worker with same configuration in stable release.
Not all matching scriptlets were injected on a given site in Optimal
or Complete mode when default mode was set to Basic or less.
A high profile manifestation of this bug was that Youtube ads were
not being blocked when using Optimal on Youtube while default mode
was Basic.
Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/229
Add "Filter lists" pane in dashboard
The DNR API now supports enabling 50 static rulesets put of a
maximum of 100 (instead of 10 out of 50 originally). Thus given
the potentially growing number of static rulesets, the available
stock rulesets has been moved to its own pane, with the following
improvements:
- Support sublists
- Support search
Aditionally, "RU AdList: Counter" has been added as a stock
ruleset.
Other changes:
- Do not re-evaluate regexes which failed validation
- Better reduce `removeparam` rules
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.
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
A new icon has been added to the popup panel, to open a popup
window with a terse list of DNR events for the current tab, in
reverse chronological order (most recent DNR event appears at
the top).
The new ability is available only when the extension is sideloaded,
as per `declarativeNetRequestFeedback` documentation. Ref:
https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest#event-onRuleMatchedDebug
Purposefully minimal, so as to have something rather than nothing
when having to diagnose filtering issue with the DNR API. Example:
https://github.com/uBlockOrigin/uBOL-home/issues/156
The content of the popup window does not dynamically update, force
a refresh (F5) to get the most recent DNR events. This might be
improved in the future.
The DNR event buffer is not persisted, so the buffer is empty when
service worker is restarted. This might be improved in the future
by using session storage API.
There is no output filtering ability in this first draft. This
might be improved in the future.
DNR rules are reported. The filter from which a DNR rule
originates is not reported. Given that the rulesets are optimized
after conversion from original filter lists to reduce the DNR rule
count, this is unlikely to ever be possible.
For internal use by filter list maintainers, do not open issues
about this. Left undocumented on purpose.
This new procedural operator allows to target elements in the
shadow root of an element.
subject:shadow(arg)
- Description: Look-up matching elements inside the shadow root (if
present) of _subject_.
- Chainable: Yes
- _subject_: Can be a plain or procedural selector.
- _arg_: A plain or a procedural selector for the elements to target
inside the shadowroot.
Example:
..##body > div:not([class]):shadow(div[style]):has(:shadow([data-i18n^="#ad"]))
