Manifest 3: WebSocket Integration

1189 views
Skip to first unread message

Mohamed Mansour

unread,
Feb 11, 2021, 4:58:40 AM2/11/21
to Chromium Extensions
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

unread,
Mar 11, 2021, 7:23:55 AM3/11/21
to Chromium Extensions, Mohamed Mansour
I would very muck like to have an answer to that question also

wOxxOm

unread,
Mar 11, 2021, 4:16:00 PM3/11/21
to Chromium Extensions, jo...@getstation.com, Mohamed Mansour
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

unread,
Jun 1, 2021, 11:23:57 AM6/1/21
to Chromium Extensions, wOxxOm, jo...@getstation.com, Mohamed Mansour
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

unread,
Jun 1, 2021, 10:53:25 PM6/1/21
to Chromium Extensions, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour
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

unread,
Jun 2, 2021, 9:47:18 PM6/2/21
to Chromium Extensions, hrg...@gmail.com, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour

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

unread,
Sep 16, 2021, 6:36:11 AM9/16/21
to Chromium Extensions, guest...@gmail.com, hrg...@gmail.com, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour
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.

Message has been deleted

Wyatt Sanders

unread,
Nov 4, 2021, 1:22:31 AM11/4/21
to Chromium Extensions, p.by...@gmail.com, guest...@gmail.com, hrg...@gmail.com, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour
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.

Message has been deleted

paul deuana

unread,
Nov 12, 2021, 7:42:19 AM11/12/21
to Fernando Velasco, Paweł Bylina, Chromium Extensions, guest...@gmail.com, hrg...@gmail.com, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour


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

unread,
Dec 2, 2021, 3:05:42 AM12/2/21
to Chromium Extensions, pde...@gmail.com, Paweł Bylina, Chromium Extensions, guest...@gmail.com, hrg...@gmail.com, vinn...@gmail.com, wOxxOm, jo...@getstation.com, Mohamed Mansour, Fernando Velasco
@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?
Reply all
Reply to author
Forward
Message has been deleted
0 new messages