Does the Chrome team recommend reverting back to Manifest v2 until MV3 bugs are fixed?

[Red ross]

Wanted to hear from the Chrome team on their stance for reverting to manifest v2 vs sticking around on Manifest v3.

We see updates about capabilities and known issues but there is no reference to the chromium issues in the MV3 architecture affecting extensions out there which have switched to MV3 or if these are even being prioritised.

Collating some of these issues here:

https://bugs.chromium.org/p/chromium/issues/detail?id=1316588
Extension listeners stop working -- including tab events / alarms / cookies / shortcuts etc, this is pretty much a show-stopper if not for the workaround in the thread. Even with the workaround, there is still an impact on user-experience.

Other bugs which seem to be on the same lines:
- https://bugs.chromium.org/p/chromium/issues/detail?id=1360358&q=manifest%20v3&can=2
- https://bugs.chromium.org/p/chromium/issues/detail?id=1337294&q=manifest%20v3&can=2
- https://bugs.chromium.org/p/chromium/issues/detail?id=1189812&q=manifest%20v3&can=2

I believe this is a serious issue that is affecting all extensions out there including on the latest Chrome version (110).

I see that the deprecation timelines are under review here, but these are to be updated in March.

Does the team recommend switching back to MV2 at this point?

[Oliver Dunk]

Hi Red,

As you mentioned, there are some known issues and we're definitely tracking those. MV3 stability is our main focus right now and everyone (me included) wants to fix these as soon as we can.

That said, I'm not sure I would agree that all extensions are being equally affected by these. There are definitely a large number of extensions already using Manifest V3 which have had a smooth rollout.

My advice would be to give migrating your extension a try and then make your own call on the stability. As you mentioned, we're reviewing the timelines, so if you encounter any issues there is some time in the short term. If everything is working well though, absolutely feel free to publish your changes!

Hope that helps.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a5cf08dc-8779-4e5a-b0f7-336c273e7fc2n%40chromium.org.

[Tom Riley]

A concern for me is how "confirmed" the existing implementations of MV3 features are (mainly the move background pages -> service workers, and the new permission for onAuthRequired).

We have a cross-browser extension and did a lot of work on updating the codebase to be MV3-ready, up until the state of things around December last year. It is a big commitment to finally make the jump, so we have been holding off until more information about what exactly is happening is available as not much seems to be sure at the moment.

This is quite a frustrating situation to be in.

[wOxxOm]

As long as ManifestV3 has that bug with service worker being randomly stuck/unregistered, advising people to migrate to MV3 without prominently mentioning this bug is completely irresponsible, but understandable because Chrome isn't a commercial software and doesn't guarantee anything, i.e. in the legal sense the team doesn't do anything wrong. Heck, even hardware/pharma companies promote products that are known to be dangerous/bugged.

[Vardhman Singh]

> That said, I'm not sure I would agree that all extensions are being equally affected by these. There are definitely a large number of extensions already using Manifest V3 which have had a smooth rollout.

I do see 21% extensions that are now on MV3 according to https://chrome-stats.com/manifest-v3-migration. However, my concern is that these could very well be plagued by these issues without any reporting on the same since these issues are quite pernicious.

FWIW I checked the source for the extensions mentioned in the original bug https://bugs.chromium.org/p/chromium/issues/detail?id=1316588
and they all seem to have rolled back to MV2.

+1 to a prominent mention of this issue in the Known Issues section on the migration page as mentioned above since APIs like tabs, shortcuts and others are critical to functionality for a lot of extensions out there and this would save everyone migrating a lot of headache.

[Simeon Velichkov]

I'm one of those 21%s. I'm not reverting, but I'm not updating it either, I just hope for that web worker race condition on register/unregister on extension update to get fixed soon. I waited for 2 years before finally moving to mv3 and I did my release a week before it got postponed again in Dec 2022. So technically my rollout went smooth, but I cannot afford dealing with mountains of complaints if I update, nor do I have the time to migrate back to mv2.

[Oliver Dunk]

Thanks everyone for all of the thoughts here.

Tom - Given that some extensions are already depending on these changes, I wouldn't expect them to change any time soon. I definitely appreciate the concern and frustration though. I totally understand waiting for our next update and hopefully when we share that it'll help to give you a better idea of what the rest of the transition will look like.

Vardhman - I completely appreciate the concern that other extensions may be hitting these. I don't think there's much more we can say on that, because without reports there really isn't anything to go on. But we definitely keep an eye on the bugs being filed (from both developers and end users) to get a feel for things. For that bug specifically, my understanding is that similar behaviour has been reported in both MV2 and MV3. It may be that the extensions you looked at are yet to attempt the migration but are still hitting this in MV2. It does seem like there's enough activity on that bug that it would be reasonable to think about adding it to the known issues doc. That said, the fact that it isn't MV3 specific might be an argument against that. I'll ask the team about it.

Simeon - Thanks for sharing that, I completely appreciate the situation you're in.

Do keep the feedback coming, we really appreciate it. I realise that it's frustrating that some of these issues take time to resolve, but we are focused on doing that.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Hao Nguyen]

Hi Oliver,

Where would be a good place to file bugs/complaints to make sure they are being looked at? I have tried posting to this forum as well as on Chromium. My experience is that there might be one or two replies, then the issue got ignored :-/

I have an extension that is pretty stuck in MV2. It is a developer tool used for modifying request and response headers (ModHeader - https://chrome.google.com/webstore/detail/modheader-modify-http-hea/idgpnmonknjnojddfkpgkljpfnnfcklj). I depend very heavily on webRequestBlocking API. However, I do not need to block any HTTP requests (my extension is definitely not an adblocker). There are certain features in the extension, such as cookie modification, appending header, URL filter, etc., that is simply too complex to implement using declarativeNetRequest. I tried migrating, but am pretty much stuck.

My suggestion for the Chrome team would be to deprecate the "cancel" field in webRequest BlockingResponse (https://developer.chrome.com/docs/extensions/reference/webRequest/#type-BlockingResponse). That would reduce the negative impact of MV3 rollout to only adblockers. Though honestly, Firefox has taken a stand of rolling out MV3 without deprecating webRequestBlocking API (https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signing-available-november-21-on-firefox-nightly/). It is best if Chrome can do the same, and simply limit the MV3 rollout to the service-worker migration plus other minor changes. Coupling too many breaking changes in a single rollout generally cause delays and lots of unhappy extension developers.

Best,

Hao

[Oliver Dunk]

Hi Hao,

As a general rule, the Chromium bug tracker (https://crbug.com/) is the single best place to track bugs and feature requests. I'm sorry that you've had a bad experience in the past. The best I can offer is to please let me know if there are particular bugs that seem to have stalled and I will do my best to follow-up on them.

On the blocking webRequest listener removal, I think an important thing to mention here is that there are several specific concerns we're trying to mitigate (the potential for abuse, and the performance implications of extension code needing to run between each request). In the majority of cases declarativeNetRequest feels like a move in the right direction there, which is why I don't think just removing the `cancel` field would be enough. Your use case is definitely an exception though.

Out of interest, have you looked at extending DevTools (https://developer.chrome.com/docs/extensions/mv3/devtools/)? I think there are some bits that would be harder but I imagine functionality like cookie modification would be possible. We also just shared https://github.com/ChromeDevTools/rfcs/discussions/4 - I wonder if that could be a path to getting some of the header modification you want (it is presumably implemented in the debugger protocol which would allow you to call the same underlying commands).

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

> the potential for abuse

Not mitigated as long as ManifestV3 allows the non-blocking webRequest.

> the performance implications of extension code needing to run between each request

Absolutely negligible in practice. Chrome team hasn't shown any data proving otherwise.

> have you looked at extending DevTools

No, a devtools extension can work only while devtools is open, whereas ModHeaders and similar extensions should always work.

[Hao Nguyen]

Exactly what wOxxOm said.

Here is my previous post with more details and links to Chromium bugs: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/UgG839bR71U/m/zH54lpaHAAAJ. I tried using Chrome DevTools Protocol as well. That too has issues as I pointed out in my previous post. Not to mention that its performance is significantly worse than webRequestBlocking API, and its UX is also worse (with a debugging banner always shown)

Hao

[wOxxOm]

>   In the majority of cases declarativeNetRequest feels like a move in the right direction there [...]. Your use case is definitely an exception though.

That's also wrong if we look at the use cases, not at the number of extensions. Thing is, the declarativeNetRequest API was intentionally designed to solve just one use case - simple rule-based ad blockers. Just one use case out of many use cases that were possible with webRequestBlocking.

[Oliver Dunk]

Thanks Hao, that's good to know.

I'm pretty sure the DevTools API lets you use the protocol without a debugging banner (I could be wrong here), but I understand the point about not wanting to force DevTools to be open.

I hadn't seen your other post with feedback but there's lots of great things there. Please do file some issues if there aren't already ones that cover it, and I'll also make sure to keep them in mind.

In general you clearly have a specific use case that we're not catering well to right now. I don't think there's anything I can say right now to help with that, since you've clearly already explored the options and limitations. I hope that as we look more at closing some of the gaps in Manifest V3 though this might be something we can tackle.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Evan Carothers]

I have to agree on this regarding the ServiceWorker issues -- our company did a huge migration to mv3 that was prioritized due to previous mv2 timelines, and we cannot go back to mv2 at this point. But the service worker is "disconnecting" constantly. I implemented a hybrid watchdog solution to try and mitigate as a workaround and even with that we're logging *MILLIONS* of restarts needed a day across our user base to keep the mv3 extension even remotely working as advertised. The only features of serviceWorkers we are leveraging are chrome.alarms and chrome.cookies.onUpdated, both of which break constantly. I agree there should be a massive red flag in the documentation or somewhere, and it's not even listed currently in the "known issues" section! Had we known about it before we certainly would not have migrated to v3--and all the headaches we've incurred--because of it. Even more frustrating, there's very little visibility across the multiple versions of this bug that have been reported regarding if the issue is actively being worked on.

[Hao Nguyen]

According to chrome-stats.com premium data, there are at least 5K active extensions that are still using webRequestBlocking API, 10 of which have 10M+ active users, including non-adblockers like:

- Honey (https://chrome-stats.com/d/bmnlcjabgnpnenekpadlanbbkooimhnj)

- Tampermonkey (https://chrome-stats.com/d/dhdgffkkebhmkfjojejmpbldmpobfkfo)

- LastPass (https://chrome-stats.com/d/hdokiejnpimakedhajhdlcegeplioahd)

- Kami (https://chrome-stats.com/d/ecnphlgnajanjnkcmbpancdjoidceilk)

I am not sure what they use webRequestBlocking API for, and whether they can replace it with DNR API, though I am sure my extension is not the only exception out there.

Whether to support webRequestBlocking API in MV3 is a simple policy decision, not an technical decision. This is something that ONLY the Chrome team can help with. Oliver, I know you are not the decision maker here. I just hope you can be a messenger to deliver the sentiment to the relevant team.

Best,

Hao

[Red ross]

It is also being reported on both MV2 (with persistent: false) and MV3 with non-persistent background page / service worker being the common theme on the bug linked above.

@Oliver I realise this is easier said than done but would the chrome team be open to adding an API to request persistence for the worker or a temporary allow-list that can allow the worker to remain persistent?

Since many folks here have some way to capture reports on whether this issue is occurring for their users but no locally reproducible repro, it would help iron out if this issue is something that breaks during the stop / start phase of the ephemeral worker or something else entirely.

[wOxxOm]

>  would the chrome team be open to adding an API to request persistence for the worker or a temporary allow-list

For special customers it's already being implemented as ExtensionExtendedBackgroundLifetimeForPortConnectionsToUrls policy since Chrome 112:

The policy's default values are extension/app origins that are known to not offer the possibility to restart an existing connection after the SW of the connecting extension was asleep:

 - Smart Card Connector

 - Citrix Receiver (stable, beta, back-up)

 - VMware Horizon (stable, beta) 

If you're a mere mortal then, evidently, no, but you can use the workarounds listed in https://stackoverflow.com/a/66618269 e.g. the offscreen document is unlimited currently so it effectively makes your SW persistent until a proper solution is devised.