3 ms·
> I'm still worried that without an MV3-compatible version of full uBlock Origin, users are still going to assume that "MV3 means that ad blockers are broken".
by gorhill 4y ago
> I'm still worried that without an MV3-compatible version of full uBlock Origin, users are still going to assume that "MV3 means that ad blockers are broken".
They currently are when compared to their MV2 counterpart.
The AdGuard MV3 version which came out earlier this month[1] shows this. Though it does its best to deal with the technical challenges which comes with MV3, the end result is poor efficiency- and reliability-wise compared to its MV2 counterpart.
This is easy for anyone to see: open the browser's own Task Manager (Esc-Shift works) and notice how the service worker associated to AdGuard MV3 is regularly (every few seconds) evicted and respawn.
When it re-spawns, the process's CPU and memory usage peaks, with memory usage shooting up to between 100-200MB. This happens repeatedly every few seconds or whenever you navigate to a new webpage.
CPU/memory efficiency has always been a primary feature of uBO, and I can't release an MV3 version suffering such efficiency setback (this on top of matching algorithm not being fully compatible with that of uBO).
However I am willing to work on an MV3 version which does not suffer no CPU/memory efficiency issues, hence uBO Lite, which takes advantage of new possibilities in MV3 to be fully declarative, at the cost of sacrificing some capabilities.
---
[1] https://news.ycombinator.com/item?id=32648131 https://news.ycombinator.com/item?id=32648131
- nightpool 4y agoI think most people would agree that it's important to add the ability to evict unused extension code from memory, which is what the fundamental move to a stateless ServiceWorker architecture is designed to support (since the previous stateful architecture required all extension background pages to be loaded regardless of whether they were actually doing anything). Being able to do that for the vast majority of extensions that that helps, without requiring extension authors to "opt in" to that change, is a very important goal. But I agree that the heuristics for when to evict certain extensions (especially those with broad all-page access permissions) definitely remains tricky, and I hear you that Chrome's are currently too severe for this type of extension to be practical. I don't think that's a fundamental problem with the service worker model though—it seems easy to add a heuristic to cover this case like "If the extension has a async network request event registered and there's an active tab open that that extension has permissions to view, be very cautious in evicting it". In that case Chrome could still want to evict the service worker i.e. if the tab/browser is in the background and paused[1], so that it wouldn't be handling event loop / network requests anyway.