smaddock

Prior to the group being formed, most discussion regarding MV3 occurred on the Chrome Extensions Google Group [0]. While feedback was accepted and open there, I hadn't seen the Chrome team acting on it to make changes. That's where most of my pessimism on the situation comes from.

I believe the Chrome team's main motivation is removing any functionality in MV3 which would have the possibility of reducing performance in normal browsing. I personally don't have much hope that they'll be backpedaling on any changes.

I've been working towards implementing greater support for Chrome extensions in Electron which has involved reading and interacting with Chromium code [0].

- Using service workers instead of a hidden background webpage is more idiomatic for web developers.

- Forced non-persistent extensions guides developers to a better implementation which relies on less resources.

*The deprecation of webRequest's blocking behavior is what's most concerning. The implementation in Manifest V2 requires sending a message back and forth between processes with JS processing for each network request which seems to be in part why they redesigned it.

However, that optimization costs so much for innovative ad blocking technologies as gorhill of uBlock Origin has mentioned. When ad blocking begins requiring new methods of detection or filtering, it'll now be up to Chromium maintainers to implement support for it in the new declarativeNetRequest API. This is a tradeoff of performance for reduced flexibility where it is absolutely needed.