Manifest v3: Communication with DevTools?

[Matthew Atkinson]

Hello,

I've not seen any mention of DevTools in the v3 docs. I was wondering if changes will be made to communication with the DevTools part of an extension?

Currently the extension I maintain uses simple message-passing between the components, but it is required to use ports for the DevTools, and the background page has to manage all of the DevTools connections and message-passing to the correct DevTools instance for a given tab.

Are there any plans to simplify this in v3?

best regards,


Matthew

[Anyware Studio]

Hi Matthew Atkinson

For the moment, the only information provided is about background.js and other script and security files that require refactoring and renaming.

You will find the answer here: https://developer.chrome.com/extensions/migrating_to_manifest_v3

[Matthew Atkinson]

Hello,

I've read that page too, but thanks for the link. As you mention, it doesn't discuss DevTools. I'm not sure how we can maintain the current approach for communicating with DevTools from content scripts when refactoring the background script into a background worker. My understanding is that the background worker will no longer be persistent, but I am not sure how to implement communication with DevTools without a persistent data structure for message dispatch.

Specifically, I'm wondering how we'll be able to implement the technique given in "Messaging from Content Scripts to the DevTools Page" in the docs <https://developer.chrome.com/extensions/devtools#content-script-to-devtools> within a background worker.

best regards,


Matthew

[Kos]

MV3 currently in "Preview/Alpha" aka "piece of crap".

[Simeon Vincent]

Matthew, I'm not aware of any DevTools changes related to MV3. While extension service workers are ephemeral, I believe that you'll be able to continue using ports for long lived connections much as you do today.

The guidance I've shared thus far regarding service worker lifetimes has been very conservative because service workers are not guaranteed to be long lived in the same way that persistent background pages are. The Service Worker spec gives the browser a good amount of leeway over a service worker's lifespan. As I understand it, the current implementation of ports increases the lifespan of the extension's service worker, but we don't make any guarantees that the service worker will not be terminated for other reasons (e.g. memory pressure).

IMO it's safest for developers to assume and design around the idea that their service worker could be terminated at any moment. If one were to assume opening a port granted a persistent background context, I imagine their extension would encounter subtle, hard to reproduce issues such as a port getting closed due to SW termination or and global variables in the background being lost.

I hope that helps clarify things; feel free to follow up with additional questions.

Kos, do you have any specific concerns with what you're seeing in Canary?

Simeon - @dotproto

Extensions Developer Advocate

--
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/f0984f06-a38c-4565-a35e-7a2a1e8da381%40chromium.org.

[Kos]

Simeon, sorry, I don't have time for checking with Canary, I guess it's better to ask nerdy guys at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json they might have some ideas.

For now I am concentrated of finding easiest way of faking service worker activity. As soon as I will find the way, I will not be disappointed in MV3 completely.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[Don Schmitt]

Since a DevTools page is an active piece of UI, I don't see why it couldn't use a SharedWorker.  The SharedWorker would have the lifetime of the page just liked a SharedWorker for a regular web page can stay alive as long as one of the documents that reference it are still alive.  Can you create a SharedWorker from your DevTools page?

Then the issue you may encounter is that Chrome doesn't (currently) allow SharedWorkers to access chrome APIs, which they should change since it wouldn't give extensions any more long-lived context than regular web pages have (i.e. the lifetime is still tied to a live user-activated isual component just like a tab).  There is a bug for this limitation:  https://bugs.chromium.org/p/chromium/issues/detail?id=1032094&q=service%20worker%20native%20messaging&can=2

-

Don

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/f0984f06-a38c-4565-a35e-7a2a1e8da381%40chromium.org.

--

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/b6c6eb4e-4c0f-494d-9db6-45c5276cfe59%40chromium.org.

[wOxxOm]

Service workers were designed for web pages, which are volatile and ephemeral entities, but extensions are essentially a part of the browser so the usage pattern of these workers is completely different. That's why an extension background service worker is kept alive as long as it has connected ports just like a background page of a ManifestV2 extension so you should have nothing to worry about. If the worker gets terminated even with messaging ports open that would be caused by something terrible that usually causes tabs to crash like an out of memory error.

[Mansoor]

Hi how are you



Sent from vivo smartphone

--

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/e612f31c-db40-4f85-9a77-a0a8bd8f119b%40chromium.org.

[Matthew Atkinson]

Hi all,

Simeon: first of all I'm sorry that I've previously typo'd your name as 'Simon' on this list!

Thanks all for your replies (particularly Simeon and wOxxOm, with respect to  my query). I'm reassured to know that I can carry on using the same technique as prescribed by the current Chrome Developer docs, and that the background service worker will be kept alive whilst there are active port connections.

However, in my extension, ports are only needed for communication between content scripts and DevTools (via the background page). It seems to me that it would fit in a lot better with the MV3 way of doing things to not need those long-lived connections, i.e. if content scripts could send messages to their respective DevTools instances (and, at least in my case, it would simplify my code). If further changes are up-for-grabs with respect to MV3, perhaps this could be considered.

best regards,


Matthew