gorhill

> it's missing the element zapper

Support for element zapper was added more than 18 months ago in version 2025.3.23.1241.[1]

---

[1] https://github.com/uBlockOrigin/uBOL-home/releases/tag/uBOLi...

> content can load without the blocker being ready to

That issue does not exist for uBO Lite. I specifically wrote in the FAQ under "What are the upsides of an MV3-based content blocker?":

> For Chromium-based browsers specifically, MV3-based content blockers which are entirely declarative will properly filter at browser launch, which is not the case for MV2-based content blockers

uBO Lite is entirely declarative, so it filters properly at browser launch, and I literally give an actual example of this in the following section, search for "filters properly at browser launch".

Cosmetic-based filters and scriptlet injection-based filters work by default, they are enforced in _Optimal_ and _complete_ filtering modes. The default filtering mode is _optimal_.

> all answers I've found in Google to this question say there is no element picker

Because Google feeds on comments like yours to answer your question about whether there is an element picker, it's bound to be wrong.

You can create your own custom filters using an element picker, and you can manually edit them. See <https://github.com/uBlockOrigin/uBOL-home/wiki/Quick-guide>.

uBO Lite does support "element picker", it's called "Create a custom filter" in popup panel.

> can't do "Block Elements"

In uBO Lite, it's called "Create a custom filter" in the popup panel.

Best is to report the issue using the "Report an issue" in the popup panel while on Reddit site. There could be other issues causing this, for instance if you didn't grant uBOL the permission to inject scripts on the site. Depending on which browser/os the issue occurs, we should be able to narrow down potential causes.

Reddit's sponsored posts are blocked by default in uBOL when using _optimal_ (default) or _complete_ mode.

I never transferred the extension in the Chrome store. The Chrome store extension has always been the one from the repository I control, and I've had full control of it since when I created it back in June 2014.

Those "adblock test" sites misinform people, they should never be used as they lead people to make bad decisions regarding their choice of content blockers.[1]

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

When trying to diagnose performance or memory issues with a browser, always start with the installed and enabled extensions.

> it claims to use zero CPU

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.

Those webpages used to "test" blockers are frowned upon, see: https://x.com/gorhill/status/1583581072197312512

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

> Doctor Feng, or similar, though I can't find

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

When you enable "Developer mode" in the "Extensions" page of your browser, you can open the developer tools for the extension by clicking the "service worker" link, and from there select the "Network" tab, you will be able all the network requests made by the extension from within its service worker.

It's working fine on Youtube in Optimal mode. If you still have issues, you will have to go through self-diagnosing steps[1] to rule out all the myriad other ways you could suffer such issues -- most commonly another extension is interfering negatively.

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

I randomly browsed the site with Firefox stable and I couldn't see any obvious malfunction. What exactly is not working? Is there a specific webpage where the malfunction can be seen?

No competent content blocker tests "ten thousand regexp matches" for each request URL to match, this is not how it works.

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

To match such URL against the tens of thousand of filters, there is only a need to lookup filters for these nine tokens, and for most of these tokens there won't be any filters to test, such that in the end for any given URL only a few to no filters will end up being tested, and the majority of these filters are not regex-based, they are just plain string matching.

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...

The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.

I see 156 distinct 3rd parties on my side if I disable the content blocker so as to let the second-, third- and nth-waves of JavaScript execute:

https://imgur.com/a/lZbUqnQ

It's perfectly fine and valid to question the pile of JS code executing in Youtube webpages, but in this specific instance the performance issues are caused by ABP/AdBlock. The issue has been acknowledged by the developers[1]. It affects only the latest version of both blockers, not previous versions, so it makes no sense to keep speculating Google is at the root of that specific issue.

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

> no problems with AdBlock plus on FF

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.

A reliable way I found to confirm whether there is new anti-content blocker code released by Youtube is to visit uBlockOrigin's reddit sub[1]:

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 isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”.

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.

> one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

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.

For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2]

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...

This was the first commit, and the commit message is accurate about the technical limitations of this first version.

If you want cosmetic filtering and other advanced filtering in the current, more mature version, you need to explicitly grant host permission for either the site or everywhere.

> uBlock to intercept http requests before rendering the web page. And from my understanding this has always been supported in Firefox, but never in Chrome.

The webRequest API does allow to intercept and cancel HTTP requests, it has been part of Chrome extensions API since 2011.

> I get a 3-5 sec lag on launch [0] as it prepares the browser to block ads.

uBO is typically ready in a fraction of second, so "3-5 sec" is not normal. In Firefox all extensions sit in the same process, so it's possible another extension is preventing uBO to be ready in a timely manner, this has happened[1].

[1] https://github.com/MetaMask/metamask-extension/issues/13163

> rare minor annoyance of cosmetic filtering (which gorhill removed for political, not technical reasons)

Please clarify.

No political motivation went into uBO Lite. It supports cosmetic filtering just fine -- it's a matter of picking the appropriate filtering mode.