Manifest V3: questions on transition plan

[Arvind Murching]

Hi,

A few questions from the Edge team-

(a) Apart from supporting intercepting requests, webRequest also enables observing and analyzing traffic.  What will be the recommended API for the latter use case, i.e., observation/analysis?

 

(b) How will deprecation be implemented for existing extensions in the Chrome Web Store?  For example, will they be afforded a timeframe within which they would be required to be updated? Will new extension submissions be rejected automatically if they use webRequest?

 

(c) How will the webRequest API continue to be supported for enterprises? Will this be through policy?

Thanks

Arvind

[PhistucK]

(a) Non-blocking (non-intercepting) webRequest is not deprecated or discouraged.

☆PhistucK

--
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/7c5498f9-5a94-49af-b242-171745a9d27a%40chromium.org.

[Arvind Murching]

Thanks.  Who might have answers to the other questions?

On Tuesday, June 11, 2019 at 11:13:21 AM UTC-7, PhistucK wrote:

(a) Non-blocking (non-intercepting) webRequest is not deprecated or discouraged.

☆PhistucK

On Tue, Jun 11, 2019 at 8:04 PM 'Arvind Murching' via Chromium Extensions <chromium-...@chromium.org> wrote:

Hi,

A few questions from the Edge team-

(a) Apart from supporting intercepting requests, webRequest also enables observing and analyzing traffic.  What will be the recommended API for the latter use case, i.e., observation/analysis?

 

(b) How will deprecation be implemented for existing extensions in the Chrome Web Store?  For example, will they be afforded a timeframe within which they would be required to be updated? Will new extension submissions be rejected automatically if they use webRequest?

 

(c) How will the webRequest API continue to be supported for enterprises? Will this be through policy?

Thanks

Arvind

--
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-extensions+unsub...@chromium.org.

[Simeon Vincent]

(a) As PhistucK said, we're not planning to remove the observational version of the webRequest API.

 

 

(b) Manifest V3 is still very much in development, so we're still ironing out the details on this.

 

In broad strokes, the plan is to provide developers with a transition period to adopt Manifest V3. Manifest V2 extensions will continue to be supported and will be able to request this permission until the transition period ends. At that point, Manifest V2 extensions will be removed from the web store and Chrome will stop loading them.

 

From the start Manifest V3 extensions won't be able to get the "webRequestBlocking" permission outside of managed environments. Since most extensions (including enterprise-focused extensions) are installed from the Chrome Web Store, including the "webRequestBlocking" permission in your Manifest V3 extension will not cause the extension to be auto-rejected when you attempt to publish.

 

 

(c) That's correct. The current plan is that extensions that are force-installed via the ExtensionInstallForcelist policy will be able to access the blocking capabilities of the webRequest API. In the future additional policies may also grant this capability, but none are currently planned.

Simeon - @dotproto

Extensions Developer Advocate

[Jeffrey Wear]

Is the manifest v3 design doc up to date? It seems to be the only doc linked from the Chrome bug tracking implementation, but it says "Updated: November 18th, 2018" and it would surprise me if there were no changes since then given the discussions on this forum and elsewhere. In particular, I would expect all of the conversations about the `webRequest` API to have resulted in some updates.

I'm interested in looking at the most up-to-date design plan so that my team can begin to spec out how we will respond to manifest v3, even in advance of the transition period you mention.

That said, is the transition period beginning soon? I thought I saw something about manifest v3 support, or at least some parts thereof, landing in Canary by the end of the summer. It would be useful to see what will / won't be supported in practice alongside the design doc.

Also, some more questions about the transition period:

* can you say about how long it might run for? (Even if you can't say exactly when it will start or end.) To know about how long we might have to make changes.

* will the team accept design feedback after the transition period starts, or will the design be locked at that point? We might have better feedback once we can see how things might actually work. And if the team won't accept design feedback at that point, then it's all the more important to consider an up-to-date design doc now.

[Jeffrey Wear]

I thought I saw something about manifest v3 support, or at least some parts thereof, landing in Canary by the end of the summer

Found what I was referencing, here:

The extensions team is currently working towards releasing a Developer Preview in the Canary channel at the end of July or beginning of August.

 So should have already happened? I haven't seen anything more about it. 

[Simeon Vincent]

Is the manifest v3 design doc up to date?

Nope. And (unfortunately) it won't be because Chromium design docs are meant as a launching off point rather than a definitive guide. I'm currently working on a transition guide akin to the Migrate to Manifest V2 or User Controls for Host Permissions guide. This will be the canonical resource for migrating to MV3. I expect that I'll need to update it based on developer feedback.

That said, is the transition period beginning soon? … So should have already happened? I haven't seen anything more about it. 

As you mentioned in the next post the extensions team is currently working toward getting a Developer Preview of Manifest V3 out. I'm hopeful about it being released this week, but no promises. Inasmuch as there's an official start to a transition period, you could argue this is it.

* can you say about how long it might run for? (Even if you can't say exactly when it will start or end.) To know about how long we might have to make changes.

Not with any specifics. We don't have an official timeline for migrating to Manifest V3. From my personal point of view, I think it will be at least a year between dev preview launch and sunsetting Manifest V2. I've been meaning to try to gather something firmer to share, but I confess other issues have demanded my immediate attention. I'll start pushing on this again.

The main goal of this preview is to let developers start experimenting with service workers as the new background context for extensions. Other features will be coming online as work progresses, such as the declarativeNetRequest API (available for experimentation now) and platform changes to prevent remotely hosted code (not yet implemented).

* will the team accept design feedback after the transition period starts, or will the design be locked at that point?

I guess it depends on the scope of the feedback. If the feedback is along the lines of "declarativeNetRequest are bad and you should feel bad," that's not going to get much traction. If the feedback is "I'm trying to do X and was able to with webRequest, but this won't work in the current implementation of declarativeNetRequest. Are there any plans to support this in MV3? Here are some ideas I think might work…", then yeah, we'd love to hear what you've got in mind.

For example, the team is pretty confident about migrating to service workers as this change will bring the extension platform more in line with the greater web platform, reduce maintenance costs, and exposes continuous web platform improvements to the extensions ecosystem. We're aware that service workers have some gaps (e.g. parsing XML/HTML) and are working with our open web counterparts to identify what capabilities would be best addressed on the web platform and what we should tackle on the extensions platform.

Simeon - @dotproto

Extensions Developer Advocate

[Jeffrey Wear]

I'm currently working on a transition guide akin to the Migrate to Manifest V2 or User Controls for Host Permissions guide. This will be the canonical resource for migrating to MV3. I expect that I'll need to update it based on developer feedback.

I think it will be at least a year between dev preview launch and sunsetting Manifest V2. I've been meaning to try to gather something firmer to share… I'll start pushing on this again.

 

Wonderful to hear!

The main goal of this preview is to let developers start experimenting with service workers as the new background context for extensions. Other features will be coming online as work progresses, such as… changes to prevent remotely hosted code (not yet implemented). 

For what it's worth, I would say that my team is most concerned about the changes to prevent remotely-hosted code. They are likely to prompt the biggest refactoring of our extension, insofar as, up until now, the vast majority of our extension's functionality has been implemented using remotely-hosted code. So I hope those changes come online on the sooner side.

By the way, I hope that you might have both technical and process changes to announce related to using remotely-hosted code. Specifically, I hope that you might be able to announce that extension review times will be guaranteed much faster if will will have to wait on review to ship critical bug fixes.