Manifest 3: WebSocket Integration

[Mohamed Mansour]

Hello,

I am trying to migrate couple of my extensions, and new ones, to Manifest 3, but I am a bit confused, I am afraid it is no longer supported to use WebSockets in Manifest 3 extensions since the background page is no longer persisted, since it is now event driven via workers.

The only way to support an extension with WebSockets is by using a full native browser environment by opening a popup/window with chrome.windows.create() and initializing the web socket there. Which is troublesome because it no longer can run in the background.

Is there a way to use workers to listen to my websocket? I am using socket.io for one, and signalr for the other. For one extension, I am using it update a popup badge, for another extension, I am doing it real-time chat.

Thank you in advance!

Mohamed Mansour

[Joël Charles]

I would very muck like to have an answer to that question also

[wOxxOm]

Opening a new tab/window as suggested by the MV3 documentation is technically a workaround, but it's not sensible in most cases, especially for an existing extension with established workflow/UX.

Here's an arguably more sensible workaround: prevent the background service worker from unloading by opening a messaging port. The worker won't unload as long as it has chrome.runtime ports open from any tab's content script or from another page of the extension. So the workaround is keep the port open for the duration of your extension's activity, be it a minute or a day. Currently the worker will reset such a connection each five minutes so you'll have to use the port's onDisconnect event to reconnect with some random tab again. The downside of this workaround is that only web pages run content scripts so if the browser doesn't have any tabs with web pages you're out of luck. Another downside is the need for content scripts on all URLs which is a broad host permission that puts most extensions in the slow review queue. Theoretically the extension might be even rejected if Chromium team continues to ignore the established fact that sometimes it's necessary to have a persistent background script for an arbitrary duration of time.

We can only hope the extensions API will provide alternative solutions someday e.g. waking the worker on a websocket event or allowing to create shared workers or allowing us to suspend the unload timer.

[Vincent Quigley]

Have we got any movement on this yet? 

Simple use case is a remote real-time event from a remote server. How can we support this in chromium?

[hrg...@gmail.com]

The best hope I know of for this kind of scenarios is the following feature proposal:

https://bugs.chromium.org/p/chromium/issues/detail?id=1128240

If this is implemented, we'll be able to create some sort of hidden browsing context, which is basically the same as the MV2 background page.

The bug has status "assigned" and label "M-93", which makes me think that something should result out of it in the coming months. Who knows.

Without this, we'll have to resort to ugly/messy/complicated workarounds.

[guest271314]

It is possible to keep background ServiceWorker from becoming "inactive" by running code ever 4.9 minutes in the ServiceWorker. I kept the same ServiceWorker instance from becoming "inactive" for 454 minutes, or over 7 hours, until I decided to stop the experiment.

Yes, Worker can listen for WebSocket connection. You can run the Worker on localhost and communicate with the Worker from any origin. The input and output can be achieved by transferables with postMessage(). On Chromium that includes Transferable Streams.

Technically an extension is not necessary, save for to turn the local services on or off.

[Paweł Bylina]

So actually, to handle WebSockets in manifest v3, we have to do some nasty tricks. This is ridiculous. Does anyone from Google has commented on this topic?

We would love to rewrite our extension to v3, but we use WebSockets and don't know how to handle them properly.

[Wyatt Sanders]

I tried starting my first chrome extension on MV3, I found code that works on MV2 with websockets, reading the chrome API documentation it looked like I could use chrome.sockets.tcp but I've had no success with that

if any Google devs are reading this could you please update the documentation and samples on github?

I am probably going to downgrade to MV2 since there's more support there.

[paul deuana]

cheers

On Sep 16, 2021, at 6:41 PM, Fernando Velasco <cuchoybiscuc...@gmail.com> wrote:



sikis

--
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/bb691c07-4d18-46d7-971b-82ced7352f5cn%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/CAGajq2AtorP%2BnN2c1%2Bdv6PVRp4i7pQpOWTwmKOuih8_h2ZQkvA%40mail.gmail.com.

[Paweł Bylina]

@Simeon are you familiar with the situation of this issue? Do we have any good solution here recommended by the Extension team?

Our extension is executing end-to-end tests in the browser (handling opening/closing tabs, opening windows etc.). We use websocket connection as a communication way to handle instructions and it cannot be handled in another way (it has to be persistent). What's the recommendation here?

[Wagner Moreira]

It doesn't look like any of the workarounds I found here and in StackOverflow are working anymore, nothing I do keeps the service worker alive in V3...

I've tried the alarms API, I tried sending messages between background.js (service worker) and the WebSocket server every few seconds, I tried keeping a promise open for a long time, and no success at all.
the service worker is shut down in less than 10seconds... it is unbelievable that we have this behavior in chrome... SO MANY extensions are going to the grave with this, and many will never be born with this issue
Has anyone from the dev team read this thread?

[Mohamad Bazzi]

I completely agree, the extension platform is being burnt to the ground and they don’t seem to care. We just have to stay vocal about it, and hope that someone listens. 

El El sáb, feb. 26, 2022 a la(s) 11:02 p. m., 'Craig Lurey' via Chromium Extensions <chromium-...@chromium.org> escribió:

This deadline from Google is crazy given the technical limitations and the chaos that this will bring. Our extension has a large number of consumer and enterprise customers. This deadline should be extended and MV2 extensions should not stop functioning in January.  Is anyone from Google reading this thread?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/efb9048f-acc1-4f15-9910-41ec403f2e86n%40chromium.org.

[JM Lambert addeective]

I believe you can maintain the wake-up state of the background service worker by listening to the Google Cloud Messaging system. I'm also aware this is painful - given the limitations of the chrome.gcm API - from server side, since you need to maintain a knowledge of all extensions instances running in the wild and organize batch of notifications to be sent on a periodic fashion. But it does not seem more complex than handling socket connections doesn't it ?