> 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_.
so I can click with cursor over element I don't want to remove it same way as in uBlock Origin?
because without UI manually editing the filter is not an element picker.
I'm unable to find any screenshot of ubol, all I found is some switch between protection levels and all answers I've found in Google to this question say there is no element picker and not going to install it since all my browser still support uBO
Thanks for your great work, I didn't notice who I am talking to.
Though it doesn't help even on official extension page in both Chrome web store and Microsoft edge add-ons store there is no clear screenshot showing this (tools dashboard after clicking More button few times), if there was clear screenshot of actual advanced/"More" UI with Element zapper/picker, users like me wouldn't have such stupid questions/assumptions and it would be clear from get go.
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.
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]
Good read: adblock test sites can be wildly inaccurate (alerting to connections that never made it, given redirect to the local shim resource) and can easily be gamed.
Next up would be looking closer at the pages you frequent. I think many people would be surprised at all the ways web apps screw up these days.
All that said, the browsers, as unfair as it may seem, should do better at handling all of the slop that web app and extension developers put out there. It’s sometimes just a whole lot easier to make the browser more bulletproof than it is to make a bajillion JavaScript/python monkeys conscientious and competent.
An alternate between those two endpoints would be to offer better tooling to enable both users and monkeys to identify things contributing to bad outcomes. I don't just mean devtools, either, I mean "oh, it seems this tab is taking up $foo memory because the background image is a 400MB .mp4 and ..." type thing. They went through all the trouble to put AI in the browser, so ask it :-/
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.
Thank you for the explanation! That makes sense now.
I'm still confused about what level of access is given to the extension and what using the extension means.
Clicking on the extension asks for access to the current website, so I'm assuming that without giving access there or clicking "Always Allow on Every Website..." in the Safari settings, the extension does not have access to the web page contents.
Basic filtering claims to not require permission to read the web page data. But the extension is still used and does content filtering right?
Maybe this is more of a comment on Safaris weird terminology in the permission settings.
I just tested with Firefox and uBlock Origin in the stricter "medium mode" and got a score of 1%. So yeah, I don't think these test pages are that great.
Would you be supportive of an "adblock test page" that literally just reports if the adblocker is working correctly, rather than how good it is? Like maybe an EICAR-like rule that is added to EasyList that matches an element on that page?
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".
reply