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.
HN user
gorhill
https://github.com/gorhill
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]
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 have still issue, you will have to go through self-diagnosing steps[1] to rule out all the myriad other ways you suffer such issues -- most commonly another extension is interfering negatively.
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:
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/...
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.
* * *
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.
There's probably a way to do this with chrome.webRequest
Network requests initiated by other extensions in their own context are not visible to other extensions through the webRequest API.
I didn't turn over the extension in the Chrome Webstore, I always have been the owner of it since I first published uBlock in June 2014.
a twitter thread that I have been trying to dig up
To turn your browser (an agent acting on your behalf) into a proprietary application (an agent acting on behalf of a website) -- i.e. the equivalent of forcing you to install a proprietary application in order to visit a website.
Extensions can have a measurable effect on the benchmark, be sure both browsers have no extension, or the same extensions with the same configuration.
My understanding:
Global warming occurs because the previous equilibrium between incoming and outgoing energy has been broken by changes in the composition of the atmosphere.
So until we reach a new equilibrium long after the atmosphere composition ceases to change, the outgoing energy will be less than the incoming energy.