[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1985170#c3

There is no claim of "zero CPU". The claim is that the service worker wakes up only when necessary -- it is designed to be suspended by default from the ground up.

In Optimal and Complete modes, the content scripts will of course execute, without the service worker being unsuspended if no filtering occurs, but perform only the necessary work and bail out ASAP if not needed.

In Basic or "No filtering" modes, no content scripts are injected.

---

Edit: Sorry, I do say "uBOL itself does not consume CPU/memory resources while content blocking is ongoing". When I say "itself" I am referring to the service worker as seen in Chromium's Task Manager. The service worker isn't required for examples when navigating to `example.com` or here at `news.ycombinator.com`. All top content blockers I have looked at do require their service worker to execute, even for merely just switching between tabs. Some even use tricks to prevent their service worker to be suspended at all.

There are many reasons that sort of online tools are not able to reliably test a content blocker:

- Many content blockers are designed to fool pages to think no content blocker is installed

- Content blockers filter according to real, actual cases, not synthetic cases used in their tests

DirectorFeng: https://www.youtube.com/channel/UCbzzMQ1mNKjAaDwbELsVYcQ

[1] https://github.com/uBlockOrigin/uAssets/issues/27415

To simplify, and speaking from uBO's perspective, consider that nine distinct tokens can be extracted from the URL in the address bar for the current webpage:

  https
  news
  ycombinator
  com
  reply
  id
  41758007
  goto
  item%3Fid%3D41757178%2341758007

This is the overall simplified explanation of how it really works, in reality it's a bit more complex because there are a lot of other optimizations on top of this.

There is a built-in benchmark tool in uBO, accessible through the dashboard, _Support_ pane, _More_ button, _SNFE: Benchmark_ button[1].

When running the benchmark against a set of 230,364 URLs, I get an average of 11-12 µs per request to perform a match test against the default filter lists in uBO.

* * *

[1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#ben...

https://imgur.com/a/lZbUqnQ

Out of curiosity I investigated these performance issues myself using profiling sessions[2] and the faulty code is definitely in the latest versions of these extensions.

* * *

[1] https://gitlab.com/adblockinc/ext/adblockplus/adblockplusui/...

[2] https://twitter.com/gorhill/status/1746543688975581604

Because it has not been updated to the problematic version, which is 5.17. In fact AdBlock on AMO is still 5.4.2, i.e. 13 versions behind latest official AdBlock version, it was last updated in Feb. 2023.

If there are well over 1,000 "here now" (near top right), this confirms the anti-content blocker code has been updated.

If well below 1,000 "here now", all is fine. At time of writing, it's fine.

* * *

[1] https://old.reddit.com/r/uBlockOrigin/

It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc.

If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place?

There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API.

This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.

My understanding is that no-review-fast-track is only for extensions which changes in DNR rulesets are only about block/allow/allowAllRequests rules.

I don't see how comprehensive content blockers can push meaningful updates with only changes to block/allow/allowAllRequests rules and nothing else.

There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]:

> When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts

* * *

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium...

[3] https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending")

[4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...