This is a first step to integrate CodeMirror6 into the project.
As a side effect, this should take care of:
https://github.com/uBlockOrigin/uBOL-home/issues/297
Though most likely the list of no-filtering websites will probably
move to its own pane as in uBO in some future.
Most of the time the URL doesn't change and just forcing a reload
of the page is sufficient. When a document is strict-blocked, the
URL must be updated however.
Excerpt from <https://openphish.com/terms.html>:
> Except as expressly permitted by OpenPhish in writing, you agree not
> to license, sell, rent, lease, transfer, assign, distribute, display,
> disclose, create derivative works or otherwise make all or any portion
> of the information obtained through the Services available to any
> third party.
onMessage() is now a listener installed synchrnously when uBOL
executes, so no longer need to deal with failure to send messages.
Related commit:
ab458b492a
Setting name: "defaultFiltering"
Type: string
Valid values: "none", "basic", "optimal", "complete"
Additionally, fix default "basic" mode toggling back to "optimal"
upon extension restart when uBOL has broad host permissions. The
default mode will toggle automatically only when there is a change
in broad host permissions status.
Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/326
uBOL now asks broad host permissions by default. Users can still
choose narrow host permissions by using their browser's controls
for this.
For instance in Chromium, those host permissions controls are found
in the "Site access" section in the detailed view of an extension.
One can set "Site access" to "On click" to revoke broad host
permissions, and grant host permissions to only specific site.
In such mode, uBOL will still block through the DNR API, but no
cosmetic or scriptlet filtering will occurs, as these requires
permission to "read and change data" on websites for which higher
filtering mode is desired.
Some browsers do not automatically grant broad host permissions
even when an extension asks for broad permissions at install time,
and going forward all browsers will likely adopt this approach, and
thus it no longer made sense for uBOL to default to no broad hosts
permissions at install time, especially given this leads to issues
with no solution -- issues solved with the new approach (e.g. like
the ability to deploy uBOL in Optimal mode by default).
Support for paths allows to narrow down specific static extended
filters to specific webpages on a given site.
Examples of usage:
example.com/toto##h1
/example\.com\/toto\d+/#@#h1
Call to postMessage was failing in the zapper when using `use_dynamic_url` in
manifest. Manually overwriting the per-session dynamic hostname with the real
extension id fixes this.
A bad test prevented the "no filtering" by default mode to not take
effect immediately when activated while no site had yet been set to
"no filtering". It would however take effect as soon as a specific
site would be excluded from "no filtering".
`generichide` option is implicitly enforced on all sites unless an
exception overrides `generichide`. Though rare, sometimes a
`generichide` exception needs to be overridden so that generic
cosmetic filtering is made possible on a specific site.
This commit is to add support for restoring generic cosmetic
filtering on sites which were excluded through a `generichide`
exception.
Concretely, this is needed to ensure the test suite can properly
verify that generic cosmetic filtering is working when the
filtering mode is set to "complete":
||ublockorigin.github.io^$generichide,important
Microsoft Edge for Android requires a "link to the core function
test cases for your Edge Android extension" to verify that the
extension function properly.
This extends coverage of strict-blocking to pattern-based filters
with `doc` filter option.
When proceeding with a URL-skip URL present, no temporary bypass
will be created when the "Don't warn me again about this site" is
left unchecked. The idea is to avoid the intermediate redirects
if we navigate again on the same strict-blocked site, while a
temporary bypass would prevent this.
uBO's "Badware risks" list has been spinned off as its own list.
The idea is that should a site be strict-blocked from that list,
we would want to know the strict-block is due to the
"Badware risks" list.
Submission to Edge Addons store fails with:
----
The following checks failed:
Package acceptance validation error:
Manifest file reference 'urlhaus.full' does not exist in the zip archive.
(Note: File locations are case-sensitive)
Package acceptance validation error:
Manifest file reference 'openphish.domains' does not exist in the zip archive.
(Note: File locations are case-sensitive)
----
Guessing the use of period in ruleset file path is causing the
issue.
Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/254
Cosmetic filters with only negated hostnames would end up being
classified as specific, while in reality the filter is generic, with
specific exceptions.
This commit fixes the improper classification. Enforcing specific
exception filters in the generic realm is still an issue to
address.
Add information about which ruleset caused a page to be strict-
blocked.
Whenever possible, add ability to URL-skip an incoming redirect
in a strict-blocked page.
Add new default list: "30-day Phishing Domain List"
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.
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/3452
Use blob-based injection only when direct injection fails because
of a page's CSP. This is a mitigation until a better approach is
devised.
Such future better approach to investigate:
- Use `MAIN` world injection supported by contentScript.register()
since Firefox 128
- Investigate registering script to inject ahead of time thru
some heuristic
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
