Updates! MV2 timeline and known issues

[Simeon Vincent]

Hey extension devs,

Today we published a couple of updates that I expect will be of interest to a lot of folks on this group.

• The More details on the transition to Manifest V3 blog post clarifies the Manifest V2 deprecation timeline. 
• The Manifest V2 support timeline to reflect these updates.
• We've published a new doc titled Known issues when migrating to Manifest V3 to give you a bit more clarity on the current state of the platform as you plan for the future.

I'm also working on a PR to get these updates on the What's New page for ease of reference in the future.

Simeon - @dotproto

Chrome Extensions DevRel

[Simon Bassu]

Hi,

How did you make the list of "Known issues"?

I don't see https://bugs.chromium.org/p/chromium/issues/detail?id=1285664#c10

which is a blocker for us

Simon B.

--
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/CAFY0HLNmgJt0NjXuZabe2%3DPvSA2%3DWJoPiFzx5hfbzLQZb74E5w%40mail.gmail.com.

[Gaurang Tandon]

Thanks for the update Simeon! Quick question: the announcement by David states that:

> “Starting in January in Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels. Starting in June in Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including stable channel.

This sentence suggests that Chrome 112 is launching in January.

Now I checked https://chromestatus.com/roadmap. In it, even the Beta for Chrome 112 is shipping in March 2023, not January or February. So did David intend to refer to Chrome 110 (which has a beta in January) or am I misunderstanding how the rollouts work here?

[Vijay Pemmaraju]

Hi Simeon, 

In the support timeline page it says:

- January 2023: Chrome Web Store stops accepting updates to existing Manifest V2 extensions

This effectively makes it so Jan 2023 is still the target for MV3, at least for us. It's too risky to have a period of time where we can't ship any updates or urgent bug-fixes to our users. Is there any leeway on this policy? It would be great if we had a couple extra months to work on and test the MV3 update, but with the above policy, that is a non-starter.

[Cuyler Stuwe]

> When it was introduced, the session storage area had an intentionally conservative maximum quota of 1 MB. We are planning to increase this limit, but have not yet settled on a new value.

It feels blatantly obvious that the bare minimum should be >= 5MB.

This would make it a drop-in replacement for any extension that expected to use window.localStorage or chrome.storage.local, given that people expect to be able to store ~5MB there.

[Moe Bazzi]

+1 this. It honestly doesnt make much of a difference than the previous policy if we cant push updates to MV2 extensions.

--

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/7dd368d7-ea03-4a6f-8c68-d4c5c677ecf0n%40chromium.org.

[Gaurang Tandon]

Hi Simeon, you mention in the known issues document that the expected timeline for off-screen documents is "Canary support around October, 2022". I am not familiar with the feature rollout plan from Canary->Dev->Beta->Stable. So I ask, will off-screen documents ship in Chrome Stable release on January 10th?

I feel it would be inconsistent to block MV2 updates in January without fully implementing the relevant APIs first, including off-screen documents, etc...

[Robbi]

@ bazz  As what I understand, we cannot send MV2 updates after January 2023.

The decision to "stretch" the timeline a bit is certainly wise, I must give them credit for it.

The only difference is that we have been given more time before our MV2 extensions are wiped out of the store (unless they are converted to MV3 in the meantime).

I hope that the same time they have given us they will also use it to fix the macroscopic bugs of the MV3 platform.

Many service worker bug reports are currently open, but many of these have not yet reached the triage stage.

[Simeon Vincent]

How did you make the list of "Known issues"?
I don't see https://bugs.chromium.org/p/chromium/issues/detail?id=1285664#c10
which is a blocker for us

Great question! The short answer is that the initial set of issues consisted of items that the Chrome team considers high priority. It goes without saying that this is vague (at best), so I'm planning to establish and share criteria that we will use in the future to determine what items are added to this list. Always be iterating, that's what I occasionally mutter to myself.

This sentence suggests that Chrome 112 is launching in January.

Now I checked https://chromestatus.com/roadmap. In it, even the Beta for Chrome 112 is shipping in March 2023, not January or February. So did David intend to refer to Chrome 110 (which has a beta in January) or am I misunderstanding how the rollouts work here?

Nope, I think you're right. This is a case where as we worked on the timeline doc we just missed this. Thanks for calling it out :)

- January 2023: Chrome Web Store stops accepting updates to existing Manifest V2 extensions

This effectively makes it so Jan 2023 is still the target for MV3, at least for us. It's too risky to have a period of time where we can't ship any updates or urgent bug-fixes to our users. Is there any leeway on this policy? It would be great if we had a couple extra months to work on and test the MV3 update, but with the above policy, that is a non-starter.

That was a mistake and has already been fixed. Sorry for the confusion.

It feels blatantly obvious that the bare minimum should be >= 5MB.

I'm hoping we can nail down and share the updated quota soon. *crosses fingers*

Hi Simeon, you mention in the known issues document that the expected timeline for off-screen documents is "Canary support around October, 2022". I am not familiar with the feature rollout plan from Canary->Dev->Beta->Stable. So I ask, will off-screen documents ship in Chrome Stable release on January 10th?

First, I want to note that the timeline info we currently have in the known issues page is more vague than I'd like. As we update this page I expect we'll also make the timelines for these features more clear. But for the initial announcement, I figured it was better to have something than nothing.

Second, in case it's helpful I tend to use https://chromiumdash.appspot.com/schedule to figure out when a given feature is likely to ship. Based on what we know right now, it looks to me like this feature may ship in 109 (feature freeze on Oct 27, 2022; branch on Nov 10, 2022; beta on Dec 1, 2022; stable on Jan 10, 2023). Ultimately, though, I can't say for sure until we get a bit closer.

Simeon - @dotproto

Chrome Extensions DevRel

[Hao Nguyen]

@Simeon, will there be any change in the policy with regards to webRequestBlocking permission? I own an extension that allows web developers to modify HTTP request and response header, and it is sophisticated enough that the simple declarativeNetRequest API just won't satisfy my extension requirements (e.g., I need to unpack the Cookie / Set-Cookie header and modify just one cookie from it, or substitute header value dynamically at runtime, etc.) I don't need to block any HTTP request. Can we consider having some sort of "webRequestModification" permission that would allow an extension to block on the webRequest's onBeforeSendHeaders and onHeadersReceived events (and may be also block on onAuthRequired), but will not be allowed to cancel the HTTP request (essentially still giving a hard-time for ad-blockers but leave the other extensions alone).

Thanks,

Hao

[Simeon Vincent]

This sentence suggests that Chrome 112 is launching in January.

Now I checked https://chromestatus.com/roadmap. In it, even the Beta for Chrome 112 is shipping in March 2023, not January or February. So did David intend to refer to Chrome 110 (which has a beta in January) or am I misunderstanding how the rollouts work here?

Nope, I think you're right. This is a case where as we worked on the timeline doc we just missed this. Thanks for calling it out :)

AHHHH shoot, I didn't read closely enough the first time. The version number here is confusing, even for me.

Normally when we reference a specific Chrome version we are usually talking about the Stable channel. In this case, though, we're talking about experimenting in the Canary, Beta, and Dev channels. Normally we bump the version number on Canary when a new branch is cut. According to Chromium Dash, Milestone 111 will be cut on Jan 26, 2023, which means that Canary will reach 112 before the end of January. 

This is all more confusing than it needs to be. Moving forward, I'd like to find a better way of communicating timeline info that doesn't require a bunch of esoteric knowledge about Chromium's release process. 

@Simeon, will there be any change in the policy with regards to webRequestBlocking permission?

No changes are currently being considered on this front. The reasons we're moving away from webRequestBlocking are rooted in its permission requirements (requires host permission grants) and execution model (imperative, sequential, multi-process). 

Simeon - @dotproto

Chrome Extensions DevRel

[Hao Nguyen]

On Thursday, September 29, 2022 at 4:37:26 PM UTC-5 Simeon Vincent wrote:

This sentence suggests that Chrome 112 is launching in January.

Now I checked https://chromestatus.com/roadmap. In it, even the Beta for Chrome 112 is shipping in March 2023, not January or February. So did David intend to refer to Chrome 110 (which has a beta in January) or am I misunderstanding how the rollouts work here?

Nope, I think you're right. This is a case where as we worked on the timeline doc we just missed this. Thanks for calling it out :)

AHHHH shoot, I didn't read closely enough the first time. The version number here is confusing, even for me.

Normally when we reference a specific Chrome version we are usually talking about the Stable channel. In this case, though, we're talking about experimenting in the Canary, Beta, and Dev channels. Normally we bump the version number on Canary when a new branch is cut. According to Chromium Dash, Milestone 111 will be cut on Jan 26, 2023, which means that Canary will reach 112 before the end of January. 

This is all more confusing than it needs to be. Moving forward, I'd like to find a better way of communicating timeline info that doesn't require a bunch of esoteric knowledge about Chromium's release process. 

@Simeon, will there be any change in the policy with regards to webRequestBlocking permission?

No changes are currently being considered on this front. The reasons we're moving away from webRequestBlocking are rooted in its permission requirements (requires host permission grants) and execution model (imperative, sequential, multi-process). 

@Simeon, webRequest has the same host permission requirements (and to some extent tabs too). Essentially a malicious extension can steal as much data using webRequest as they can with webRequestBlocking. Are you implying that webRequest will be subjected to deprecation in the future too? Otherwise it does not make sense to single out webRequestBlocking permission. webRequest is also imperative and multi-process. The only difference is that it is non-blocking, so not sequential. That is the only valid argument I can see for deprecating webRequestBlocking but not webRequest. But seriously, the few extra nanoseconds (or even milliseconds) spent on sequential executions will save users minutes (possibly even days/weeks) of time compared to using an alternative solution (e.g., setting up a proxy server).

debugger API (https://developer.chrome.com/docs/extensions/reference/debugger/) with Fetch domain (https://chromedevtools.github.io/devtools-protocol/tot/Fetch/) is also imperative, sequential, multi-process. Is it subject to future deprecation as well? (I own another extension that relies extensively on debugger API so want to make sure...)

[wOxxOm]

AFAIK, Chromium team dislikes the blocking behavior (which is not about blocking requests per se but about blocking the internal execution flow in Chrome, which is also necessary to modify requests) because its multi-process architecture has become too complicated over the years for them to maintain, so in the end it's not about real performance problems (practically there are none in 99.9999% of cases), but rather the pain they feel each time they have to deal with any network-related code where even subtle changes can introduce subtle bugs that can leak sensitive info. As a programmer I can certainly relate to that, not as a user though :-)

[wOxxOm]

...to elaborate, the blocking part of the multi-process architecture is especially challenging for them because it requires complicating the logic to the point it becomes indiscernible due to the need for synchronization locks over many places at many points in the request flow.

[Hao Nguyen]

Well, if the Chromium team needs to keep webRequestBlocking permission around for enterprise users, then that code is not going away so they will still need to maintain it, and as I pointed out earlier, Chrome DevTools Protocol also has similar blocking behavior, so these logics are not getting any simpler. My guess is that supporting declarativeNetRequest API probably made that codes even more complicated.

I can understand Googlers' undying desire to create impact by driving large-scale migration and deprecating things before the replacement is ready. That said, none of the reasonings for killing webRequestBlocking seems legit. It is more like someone has already decided that they need to get rid of webRequestBlocking permission, then scramble to put together some obscure reasonings to defend that decision, rather than the other way around.

[hrg...@gmail.com]

The reason for removing the blocking functionality of WebRequest is that it requires executing Javascript for every request and the browser must wait for that Javascript to finish each time. People at Google don't like this because it slows down the entire process.

They've learned throughout the decades that the best way to keep people browsing non-stop is to load pages as quickly as possible.

When things are slow, people get frustrated and go away, which means Google's source of revenue is affected. This is why at Google they value speed over functionality.

[wOxxOm]

Guesses aside, on a factual side they still don't take the situation seriously, it's still a fun ride for them, the announcements are full of corporatese lingo about improved safety and security. Even the technical article says "As Manifest V3 approaches full feature parity with Manifest V2, we'll be progressively phasing out Manifest V2". While this definitely sounds reasonable if you don't know the context, but given the subsequently plotted timeline it becomes a gross exaggeration and a borderline lie, because with the progress rate we all observed over the past years it'll take at least several years more for MV3 to become reliable and feature-rich enough to replace MV2, not half a year or a year. Neither the issue list nor the announcement acknowledge that MV3 is still half-broken and unusable for anything other than a beta test due to its unreliable registration of service worker that break extensions completely for thousands of users, soon for millions because no one in Chromium has yet found out the exact reason of the bug, hence they can't be sure they'll fix it in the next months.

[John Blair]

Hi @simeon,

I appreciate that there will be lots of bugs being raised and that there are challenges in prioritising, but I wanted to highlight 1299742

In short - MV3 content scripts can't click a web page link with a javascript: URL due to the new CSP policy: e.g
  <a href="javascript:console.log('foo')">Link Text</a>

The target site is owned by a third party it is not something that is in our control. Our extension does not violate the CSP policy - the target site does. All we want to do is simply click a link, and it seems overly restrictive that we can't do that.

The bug above was raised in February and has not even been triaged. It is a complete showstopper for our extension and the deadline for V3 looms ever closer. We need to know if there is a likelihood of this being treated as a bug and fixed, or whether we need to find some nasty workaround. I've been waiting and waiting as the months go by to see if this would be addressed, but without the issue even being triaged it's impossible to know what to do. 

Please, can you provide any information on this. 

Thanks

John 

[Howard Combs]

Hi Simeon,

I had a followup question regarding 

• Staring in Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels.

These experiments won't affect stable releases? IE could chrome users could have Manifest V2 extensions turned off without notification? We have been planning our timetable for V3 upgrade and want to know if existing users might experience interruptions in 2023 using our v2 extension.

[nem...@readcube.com]

so does all this means that manifest v2 extensions will still be able to be updated through developer web store until January 2023? and also users using stable version of chrome will still be able to update same extension through store at least until June 2023?

[Péter Szász]

Hi Simeon,

I'm bringing my thread up from last week in this related thread to ensure visibility. We have some questions around the MV3 milestones and what they mean in detail - it would be great to get some clarity even on some of the items, if all is not possible for some reason.

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/rQkT2jsqSjc/m/AOwG2x3BBwAJ

Thanks if you can add some light,

Péter