1
0
mirror of https://github.com/gorhill/uBlock.git synced 2024-11-26 12:22:50 +01:00
Commit Graph

50 Commits

Author SHA1 Message Date
Raymond Hill
0b09155268
Clear unprocessed requests status on webNavigation reload event
Related feedback:
- https://github.com/uBlockOrigin/uBlock-issues/discussions/2564
2023-03-30 17:12:45 -04:00
Raymond Hill
1835e90125
Avoid using ! toolbar icon badge when inconsequential
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
2023-03-30 12:30:44 -04:00
Raymond Hill
10f9559a52
Add 64px toolbar icon for 4K displays
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2477
2023-03-27 12:59:39 -04:00
Raymond Hill
2f42cf61ab
Properly handle potential exception from webext API
Related feedback:
- https://github.com/uBlockOrigin/uAssets/discussions/16939#discussioncomment-5356808
2023-03-19 07:25:06 -04:00
Raymond Hill
60827c603d
Cached managed storage content for faster readiness
Related issue:
- https://github.com/uBlockOrigin/uAssets/discussions/16939
2023-03-18 17:23:13 -04:00
Raymond Hill
bb462e6e5d
Actual icon color is #FFCC00, not #FC0 2023-03-18 12:27:40 -04:00
Raymond Hill
a72c068bcc
Make badge color consistent with filtering status
Related commit:
- 32508620a2
2023-03-18 12:16:20 -04:00
Raymond Hill
32508620a2
Emphasize broken filtering at launch on toolbar icon badge
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.
2023-03-18 11:35:06 -04:00
Raymond Hill
769b8da664
Finalize "unreadiness" toolbar icon
- Yellow uBO toolbar icon: uBO not ready

- Yellow uBO toolbar icon + `!` badge: network requests went
  through while uBO is not ready
2023-03-16 07:13:27 -04:00
Raymond Hill
39cac612c2
Use the warning toolbar icon only if unprocessed requests
Related discussion:
- https://github.com/uBlockOrigin/uAssets/discussions/16939

Related commit:
- 0c9576d3e6
2023-03-15 21:13:28 -04:00
Raymond Hill
f9b03ebeac
Report unprocessed network request count in troubleshooting info
Related discussion:
- https://github.com/uBlockOrigin/uAssets/discussions/16939
2023-03-08 09:36:09 -05:00
Raymond Hill
0c9576d3e6
Show a distinct toolbar icon until filtering engines are fully initialized
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.
2023-03-07 16:02:09 -05:00
Raymond Hill
454a03a98f
Use block scope to isolate context 2023-02-24 18:02:28 -05:00
Raymond Hill
e2c3917ecd
Unconditionally set label of toolbar icon
Related feedback:
- https://github.com/uBlockOrigin/uBlock-issues/discussions/2409
2022-12-15 10:04:03 -05:00
Raymond Hill
a91781a495
Rewrite logger's "exceptor" feature
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1861

The "exceptor" feature has been rewritten, with the following
changes as a result:

- The excepted filters cease to exist when closing the logger
- It's now possible to temporary except network filters

When toggling on/off a temporary exception, filter lists are now
fully reloaded. This simplified managing temporary exceptions, and
made it easy to implement temporary exception for network filters,
but this also means there might be a perceptible delay when
adding/removing temporary exceptions. At this point I consider
this an acceptable side-effect just to bring the ability to easily
create temporary exception for network filters, while this
simplified the existing temporary exception code throughout.
2022-12-14 16:04:45 -05:00
Raymond Hill
58e60d6d96
Fix various regressions in latest dev build
Related issues:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2404
- https://github.com/uBlockOrigin/uBlock-issues/issues/2400#issuecomment-1346050327
2022-12-12 14:02:57 -05:00
Raymond Hill
0bfffb80c4
Fix spurious warning
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2243
2022-10-05 07:28:01 -04:00
Raymond Hill
a71b71e4c8
New cosmetic filter parser using CSSTree library
The new parser no longer uses the browser DOM to validate
that a cosmetic filter is valid or not, this is now done
through a JS library, CSSTree.

This means filter list authors will have to be more careful
to ensure that a cosmetic filter is really valid, as there is
no more guarantee that a cosmetic filter which works for a
given browser/version will still work properly on another
browser, or different version of the same browser.

This change has become necessary because of many reasons,
one of them being the flakiness of the previous parser as
exposed by many issues lately:

- https://github.com/uBlockOrigin/uBlock-issues/issues/2262
- https://github.com/uBlockOrigin/uBlock-issues/issues/2228

The new parser introduces breaking changes, there was no way
to do otherwise. Some current procedural cosmetic filters will
be shown as invalid with this change. This occurs because the
CSSTree library gets confused with some syntax which was
previously allowed by the previous parser because it was more
permissive.

Mainly the issue is with the arguments passed to some procedural
cosmetic filters, and these issues can be solved as follow:

Use quotes around the argument. You can use either single or
double-quotes, whichever is most convenient. If your argument
contains a single quote, use double-quotes, and vice versa.

Additionally, try to escape a quote inside an argument using
backslash. THis may work, but if not, use quotes around the
argument.

When the parser encounter quotes around an argument, it will
discard them before trying to process the argument, same with
escaped quotes inside the argument. Examples:

Breakage:

    ...##^script:has-text(toscr')

Fix:

    ...##^script:has-text(toscr\')

Breakage:

    ...##:xpath(//*[contains(text(),"VPN")]):upward(2)

Fix:

    ...##:xpath('//*[contains(text(),"VPN")]'):upward(2)

There are not many filters which break in the default set of
filter lists, so this should be workable for default lists.

Unfortunately those fixes will break the filter for previous
versions of uBO since these to not deal with quoted argument.
In such case, it may be necessary to keep the previous filter,
which will be discarded as broken on newer version of uBO.

THis was a necessary change as the old parser was becoming
more and more flaky after being constantly patched for new
cases arising, The new parser should be far more robust and
stay robist through expanding procedural cosmetic filter
syntax.

Additionally, in the MV3 version, filters are pre-compiled
using a Nodejs script, i.e. outside the browser, so validating
cosmetic filters using a live DOM no longer made sense.

This new parser will have to be tested throughly before stable
release.
2022-09-23 16:03:13 -04:00
Raymond Hill
e31637af78
[mv3] Add ability to enable/disable filter lists 2022-09-13 17:44:24 -04:00
Raymond Hill
a559f5f271
Add experimental mv3 version
This create a separate Chromium extension, named
"uBO Minus (MV3)".

This experimental mv3 version supports only the blocking of
network requests through the declarativeNetRequest API, so as
to abide by the stated MV3 philosophy of not requiring broad
"read/modify data" permission. Accordingly, the extension
should not trigger the warning at installation time:

    Read and change all your data on all websites

The consequences of being permission-less are the following:

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

At this point there is no popup panel or options pages.

The default filterset correspond to the default filterset of
uBO proper:

Listset for 'default':
  https://ublockorigin.github.io/uAssets/filters/badware.txt
  https://ublockorigin.github.io/uAssets/filters/filters.txt
  https://ublockorigin.github.io/uAssets/filters/filters-2020.txt
  https://ublockorigin.github.io/uAssets/filters/filters-2021.txt
  https://ublockorigin.github.io/uAssets/filters/filters-2022.txt
  https://ublockorigin.github.io/uAssets/filters/privacy.txt
  https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt
  https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt
  https://ublockorigin.github.io/uAssets/filters/unbreak.txt
  https://easylist.to/easylist/easylist.txt
  https://easylist.to/easylist/easyprivacy.txt
  https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt
  https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext

The result of the conversion of the filters in all these
filter lists is as follow:

Ruleset size for 'default': 22245
  Good: 21408
  Maybe good (regexes): 127
  redirect-rule= (discarded): 458
  csp= (discarded): 85
  removeparams= (discarded): 22
  Unsupported: 145

The fact that the number of DNR rules are far lower than the
number of network filters reported in uBO comes from the fact
that lists-to-rulesets converter does its best to coallesce
filters into minimal set of rules. Notably, the DNR's
requestDomains condition property allows to create a single
DNR rule out of all pure hostname-based filters.

Regex-based rules are dynamically added at launch time since
they must be validated as valid DNR regexes through
isRegexSupported() API call.

At this point I consider being permission-less the limiting
factor: if broad "read/modify data" permission is to be used,
than there is not much point for an MV3 version over MV2, just
use the MV2 version if you want to benefit all the features
which can't be implemented without broad "read/modify data"
permission.

To locally build the MV3 extension:

    make mv3

Then load the resulting extension directory in the browser
using the "Load unpacked" button.

From now on there will be a uBlock0.mv3.zip package available
in each release.
2022-09-06 13:47:52 -04:00
Raymond Hill
0c9ab84846
Fix redundant calls to extract image data
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2243#issuecomment-1236194011
2022-09-04 10:40:26 -04:00
Raymond Hill
127ea05a9e
Replace responsive with intab for better remdering og panel in a tab
Related feedback:
- https://github.com/uBlockOrigin/uBlock-issues/issues/2116#issuecomment-1143634719
2022-06-04 11:12:45 -04:00
Raymond Hill
1c090f0fae
Use string template 2022-06-03 12:27:51 -04:00
u-RraaLL
614b8328e9
Update popup url
Fix broken functionality caused by the removal of the classic popup.
2022-05-21 09:42:08 +02:00
Raymond Hill
60072e7996
Minor code review
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1992
2022-02-18 06:52:34 -05:00
Raymond Hill
e1e2ba3d5d
Use unspoofable Messenger.origin to determine privilege level of ports
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1992
2022-02-17 18:05:01 -05:00
Raymond Hill
3154ed1bac
Remove test for whether Chromium version is less than 66
The test is no longer needed given that the minimum supported
version is Chromium 66.
2022-02-17 09:07:56 -05:00
Raymond Hill
2933016d4b
Rework behavior of "Suspend network activity until ..."
The setting will default to the natural capability of the browser:

- Checked for Firefox
- Unchecked for Chromium-based browsers

For Chromium-based browser, if checked, network requests will be
redirected to an empty resources instead of blocking the
connection.

Related feedback:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1973
- https://www.reddit.com/r/uBlockOrigin/comments/squo8n/latest_update_blocks_network_connections_at/
2022-02-13 09:24:57 -05:00
Raymond Hill
a2d83afe66
Further narrow when unconditionally calling webRTCIPHandlingPolicy.clear()
The enabled cached state probably exists in the browser only
when the setting was originally enabled -- so we need to clear
it only in such case.
2022-02-06 09:00:25 -05:00
Raymond Hill
00b257caa7
Unconditionally call webRTCIPHandlingPolicy.clear() at launch
On Chromium-based browsers only.

Related issue/feedback:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1928
- https://www.reddit.com/r/uBlockOrigin/comments/sl7p74/
2022-02-05 12:04:08 -05:00
Raymond Hill
eddb9ec160
Raised guessed Firefox version to 91 (latest ESR) 2022-01-09 12:41:29 -05:00
Raymond Hill
d38c19cabf
Improve test for presence of browser as extensions API
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1914

The issue affected only Chromium-based browsers.
2022-01-01 11:07:17 -05:00
Raymond Hill
925c8d5d0c
Add setting to control suspension on network activity at launch
Related discussion:
- a0a9497b4a (commitcomment-62560291)

The new setting, when disabled (enabled by default), allows a user
to prevent uBO from waiting for all filter lists to be loaded
before allowing network activity at launch. The setting is enabled
by default, meaning uBO waits for all filter lists to be loaded in
memory before unsuspending network activity. Some users may find
this behavior undesirable, hence the new setting.

This gives the option to potentially speed up page load at launch,
at the cost of potentially not properly filtering network requests
as per filter lists/rules.

For platforms not supporting the suspension of network activity,
the setting will merely prevent whatever mechanism exists on the
platform to mitigate improper filtering of network requests at
launch. For example, in Chromium-based browsers, unchecking the
new setting will prevent the browser from re-loading tabs for
which there was network activity while in "suspended" state at
launch.
2021-12-30 09:24:38 -05:00
Raymond Hill
ca1ec1461b
Narrow usage of webRTCIPHandlingPolicy to only firefox
In addition of `mobile`, just in case -- some people are
using mobile version of chromium out there.
2021-12-11 07:37:18 -05:00
Raymond Hill
b1a338681b
Shield against possible case of invalid attribute name
Not sure this can really happen, but if ever Math.random() would
return `0.9999999999999999`, the attribute name would start with
`{`, i.e. an invalid attribute name.
2021-10-26 08:55:05 -04:00
Raymond Hill
318469b005
Remove unused function 2021-10-22 08:34:04 -04:00
Raymond Hill
18ae79cdf2
Remove unused code path as per current minimum browser version 2021-10-17 13:50:43 -04:00
Raymond Hill
e4d75fa025
Ignore unused tabs.onUpdated() events 2021-10-17 12:55:31 -04:00
Raymond Hill
b0038eac28
Remove unused code path
Versions of Firefox 54 and lower are no longer supported.
2021-10-13 11:17:21 -04:00
Raymond Hill
c4b7ee80ea
Further work on JS modules
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1664
2021-10-07 14:41:29 -04:00
Raymond Hill
4100761863
Keep ability to prevent local IP address leaks for mobile version
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1723

Related feedback:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1723#issuecomment-919913361
2021-09-15 08:28:10 -04:00
Raymond Hill
831cf478da
Revert "Remove now obsolete webrtc-related setting"
This reverts commit af41aadab7.
2021-09-15 07:40:32 -04:00
Raymond Hill
af41aadab7
Remove now obsolete webrtc-related setting
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1723

The leaking of local IP addresses is no longer an issue
in modern browsers.
2021-09-14 10:04:35 -04:00
Raymond Hill
cbec7397fc
Fix jshint warnings
Those warnings surfaced as a result of removing the braces
used to create a local namespace.
2021-08-03 12:08:59 -04:00
Raymond Hill
2eb02c5adc
Fix spurious error message in dev console
Ports can be disconnected under certain conditions,
and in such case runtime.lastError must be accessed
to avoid the extensions framework from emitting
error messages in the console.
2021-07-31 07:20:38 -04:00
Raymond Hill
98fc66bb1b
Add support for enabling WASM code paths in NodeJS package
See `test.js` for reference on how to enable WASM code
paths (which are disabled by default).
2021-07-29 16:54:51 -04:00
Raymond Hill
22022f636f
Modularize codebase with export/import
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/1664

The changes are enough to fulfill the related issue.

A new platform has been added in order to allow for building
a NodeJS package. From the root of the project:

    ./tools/make-nodejs

This will create new uBlock0.nodejs directory in the
./dist/build directory, which is a valid NodeJS package.

From the root of the package, you can try:

    node test

This will instantiate a static network filtering engine,
populated by easylist and easyprivacy, which can be used
to match network requests by filling the appropriate
filtering context object.

The test.js file contains code which is typical example
of usage of the package.

Limitations: the NodeJS package can't execute the WASM
versions of the code since the WASM module requires the
use of fetch(), which is not available in NodeJS.

This is a first pass at modularizing the codebase, and
while at it a number of opportunistic small rewrites
have also been made.

This commit requires the minimum supported version for
Chromium and Firefox be raised to 61 and 60 respectively.
2021-07-27 17:26:04 -04:00
Raymond Hill
c9710ac9d1
Better deal with no-longer-existing ports
Disconnected ports could still happen Even when the port
was still seen as valid internally. Using a try-catch
block makes invalid port detection more reliable. This
is an occurrence I often encountered when stepping into
content script code, causing suprious error messages to
be thrown into uBO's background dev console.
2021-07-19 11:25:52 -04:00
Raymond Hill
bad1506f20
Move chromium-specific code path to chromium directory 2021-07-16 10:29:39 -04:00
Raymond Hill
a4aced69dc
Reorganize platform directory to avoid Chromium-centric appearance
Though Firefox shares a lot of WebExtensions code with Chromium,
these platforms have their own specific code paths, for various
reasons.

The reorganization here makes it clear that Chromium platform is
just one flavor of WebExtensions, and as such all Chromium-specific
code paths should no longer be automatically pulled by other
platforms where these code paths are not needed.

Given that the filepath of many files changed, here is the
parent commit to quickly browse back to the previous directory
layout:

ec7db30b2f
2021-07-16 10:06:58 -04:00