Migration from V2 to V3

[Tomasz Ścisło]

Hi!

I have extension that is using some of the features that are not available in v3, like:

1. use-eval CSP

2. Background page

3. Usage of some deprecated APIs

4. Need for a persistent service worker

5. No window and DOM access in service worker, when in the past it was available in background page

6. Loading external scripts CSP

As you can see the list of incompatibilities is huge. Now to the question ;)

TLDR;

Taking into account that deadline for migration to V3 is 1.2023 why none of the big players extensions (like some prominent ad blockers) haven't migrated to V3? Maybe it is not worth to migrate at this point because there still will be some breaking / major changes in V3 extension's requirements? 

[hrg...@gmail.com]

Precisely. MV3 is still not production-ready. Many bugs and missing features make MV3 a headache to deal with at the moment.

[Tomasz Ścisło]

Yes I agree that is is not prod ready. But I don't think they will abandon the whole concept of background service worker which essential is the whole pain in the neck... Maybe they will fix some bugs add some missing features but essentially I think that service worker will stay. 

What do you think?

Also are there ppl on this group postponing their migration because there might be some significant braking changes in v3 spec?

[hrg...@gmail.com]

The non-persistent service worker will stay at least for a few years after MV2 dies, so we have no choice but to deal with that.

However, MV3 is still buggy and incomplete to the point that many extensions can not be migrated till this day.

For example, MV3 still provides no way of executing user-provided scripts. This feature is essential for user-script managers such as GreaseMonkey or TamperMonkey and in general any extension that allows the user to extend the functionality with snippets of Javascript.

There's also no way of performing DOM operations in the background. This is another essential feature for so many extensions which will supposedly be solved with the new "offscreen documents". But who know when that will see the light of day.

Also, still no way of obtaining favicons, which is another essential requirement for all those bookmark manager extensions as well as some types of New Tab Page extensions.

So, many of us have no choice but to keep waiting for MV3 to provide the functionality we need.

[Tomasz Ścisło]

I thought that the easiest solution for me would be to go with " "Forever", via a dedicated tab, while the tab is open" mentioned here: https://stackoverflow.com/questions/66618136/persistent-service-worker-in-chrome-extension

But now I'm curious about those "offscreen documents" do you have more insights about that?

[wOxxOm]

The offscreen documents API is being implemented already and you can try it in its current incomplete/buggy form in Chrome Canary by adding a command line switch to the browser shortcut:  --enable-features=ExtensionsOffscreenDocuments

It requires "permissions": ["offscreen"] (implemented) and an "offscreen" dictionary in manifest.json (not implemented yet).

Then you can run it like this: chrome.offscreen.createDocument({url: 'test.html', justification: 'foo', reasons: ['TESTING']})

The test.html page can do anything a DOM page can do, except navigate itself, its `chrome` API is limited to chrome.runtime.sendMessage and connect.

[Tomasz Ścisło]

Thanks! That looks promising. You said that "test.html" can do anything a DOM page can do, so can it:

1. Have it's own CSP defined and request external scripts, fetch XHR etc?

2. Live forever provided that extension is loaded in the browser? It is not removed from memory, put to sleep etc?

How likely this "offscreen documents API" will become publicly available by the time v3 extensions are mandatory, which is Jan 2023?

--

Kind Regards / Pozdrawiam

Tomasz Ścisło
sci...@gmail.com

http://scislo.eu

http://mobilenext.scislo.eu

[wOxxOm]

I didn't test it myself.

[Simeon Vincent]

Before I get to some specific replies, I wanted to quickly note that this discussion reminded me that I'm overdue to create a known issues document. I don't have a specific timeline on when I'll be able to get a final document published, but I've at least kicked off the effort in the mv3-known-issues branch of our documentation project.

MV3 still provides no way of executing user-provided scripts. This feature is essential for user-script managers such as GreaseMonkey or TamperMonkey and in general any extension that allows the user to extend the functionality with snippets of Javascript.

We're very conscious of this gap and are planning to address it as soon as we can. I'll share more in this group when I have more concrete details that I can discuss.

There's also no way of performing DOM operations in the background. This is another essential feature for so many extensions which will supposedly be solved with the new "offscreen documents". But who know when that will see the light of day.

Ah shoot, wOxxOm beat me to the punch. Doesn't hurt to mention it here again, though.

Offscreen Documents is very much a work in progress, but work is taking place behind a feature flag in Canary. Since we're so early we don't have docs prepared for it yet, but the adventurous among us can start to experiment with it by launching canary with the following CLI flag: --enable-features=ExtensionsOffscreenDocuments and consulting the relevant unit test extension. 

I'm aiming to have reference material on how we're thinking about this capability and the API itself on developer.chrome.com when we land it in Canary without a feature flag.

How likely this "offscreen documents API" will become publicly available by the time v3 extensions are mandatory, which is Jan 2023?

Extremely.

[can an offscreen document]

1. Have it's own CSP defined and request external scripts, fetch XHR etc?

Offscreen documents do not have a separate CSP. If you want to fetch external scripts, you will need to do so inside a sandboxed page (currently blocked on crbug.com/1220994). Note that you can load a sandboxed page inside an iframe in a sandboxed document.

[can an offscreen document]

2. Live forever provided that extension is loaded in the browser? It is not removed from memory, put to sleep etc?

No. Offscreen documents are not persistent. The lifetime of an offscreen document is independent of an extension's service worker, but they are explicitly not intended to be a replacement for persistent background pages or event pages. I believe offscreen documents have a fixed maximum lifetime in the current Canary implementation. As we continue to develop this feature, this single fixed lifetime will be replaced by reason-specific lifetimes. 

Think of offscreen documents as a way to perform a specific task that requires DOM capabilities (e.g. playing audio), not as an invisible page with an unbound lifetime.

Simeon - @dotproto

Chrome Extensions DevRel

--
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/7c27dbf9-82c5-455d-9356-431344251a98n%40chromium.org.

[Tomasz Ścisło]

Thank you Simeon for you explanation here!

I think that I finally found the right place and people to talk to about this migration.

I'm really sad that you said that 'Offscreen documents' lifetime will be limited. In general I understand that you don't want for it to be replacement of background pages but that would definitely made my migration way easier.

Can you elaborate more on sandboxed page? Is there any documentation to read about that?

Is there any chance that you will postpone mandatory switch to M3 beyond 1.2023 taking into account how many bugs we have and how many missing features there are?

Maybe you would be also able to help me on how I should go about my migration having in mind what I currently have in my extension:

1. I have background page that uses custom HTML that is written in Angular. This have the following implications: a) Angular uses eval underneath b) I need DOM access c) I need do download and execute external scripts

2. I'm using Google Chrome specific extension API in my background page, such as messaging, storage, tabs, inject

3. This background page injects scripts to some of the tabs and communicates with them

Thank you!

[Tomasz Ścisło]

4. From what I know currently such communication does not keep service worker alive. It gets terminated after 5 mins without some specific hacks mentioned here. Any advise on how to handle this case?

[Nurlan Nurmanov]

Based on all the input here, what would be the recommended path to develop a new Chrome extension? Should I go ahead and build everything on MV2 and migrate when MV3 is ready or I should start everything on MV3? I have tight schedule and I don't want to be at the bleeding edge with MV3.

[Adis Nabawi Azizan]

I'm currently use MV3 as my chrome  extension. It's a simple extension and only targeted group of people. I developed mostly with vanilla JS and JQuery. Not yet approved but hope for the best. 

[Tomasz Ścisło]

If I were you I would start with v3 even though it is not final yet. If you go with v2 by the time you finish development and validation process you will need to migrate to v3 so, there is no point.

[avm99963]

Also, as per https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/ (haven't verified it myself), the CWS is no longer accepting new MV2 extensions. So if you wanted to host them in the CWS, that would rule out developing it with MV2.

[Andrey Vyrvich]

Simeon, how will the review process work? I feel like around December-January there will be thousands and thousands of extensions uploaded to the store. What will happen to those mv2 extensions that will be pending review for their mv3 update - will they stop working in January? Is there an exact date when mv2 extensions stop working?