Re: [crx] websocket connections in event pages (or a websocketRequest API)

[Abraham Williams]

WebSockets use a persistant connection so if your extension uses them you will have to stick to the traditional style of background pages.

Abraham
--
Abraham Williams | abrah.am | abraham+ | addvocate.co

This email is: [ ] shareable [x] ask first [ ] private

On Thu, Aug 30, 2012 at 11:33 AM, Ahmet Akyol <liq...@gmail.com> wrote:

How about having a websocket connection in our event pages? It's clearly against the idea behind event pages.

I was hoping to use only one websocket connection in a background page which will be open all the time and handle server-side requests. I guess you know better than me what websocket brings to the table in terms of performance and being bi-directional.

So what is your advice in such a use case? If I have to underline the use case's most important part, I need "only one websocket connection for the extension that is always open".

I am not an expert like you guys but maybe we need a new API (let's call it websocketRequest API) which provides a websocket connection for extension itself that is always open without a background page. We can define it in the manifest file and also chrome may handle reopening-reconnection stuff.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/gVcje7fU6j4J.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

[Paweł Bylina]

But manifest v3 is removing background pages. What's the alternative then? 

[Alexander Harding]

*crickets*

[Simeon Vincent]

You can use push messages (either chrome.gcm or the Push API) to wake a service worker. Once awake, you can use HTTP requests or a websocket connection to send updates to your server while the service worker is alive. If you have UI injected into a web page or on a dedicated extension page, you can open a websocket connection from that context. If you go this route, you may also want to consider automatically terminating the websocket connection when the current tab loses focus and reconnecting from the newly focused page.

Simeon - @dotproto

Chrome Extensions DevRel

On Wed, Dec 15, 2021 at 3:50 PM Simeon Vincent <sim...@google.com> wrote:

You can use push messages (either chrome.gcm or the Push API) to wake a service worker. Once awake, you can use HTTP requests or a websocket connection to send updates to your server while the service worker is alive. If you have UI injected into a web page or on a dedicated extension page, you can open a websocket connection from that context. If you go this route, you may also want to consider automatically terminating the websocket connection when the current tab loses focus and reconnecting form the newly focused page.

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

“Use a Google product”… one whose first link lands you on a deprecation page. 😬

… Every single other link I tried on the GCM page takes you to a 404.

And, following Google’s track record of poor support, whatever remains of this service will probably be gone in a year or two.

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/CAFY0HLNxk-7FsbfrOs9WFu_M7Wk7GvFCpPqNX3aGZU_-GGT%2BUw%40mail.gmail.com.

[Simeon Vincent]

chrome.gcm was originally implemented using Google Cloud Messaging, but moved over to Firebase Cloud Messaging in … 2020 I think? The API's namespace didn't change because we felt that it would introduce unnecessary breakage for extension developers.

Thanks for calling out the documentation issues. I'll tag some folks and try to get this cleaned up.

Simeon - @dotproto

Chrome Extensions DevRel

[Paweł Bylina]

Can we use chrome.gcm and will it be supported or is it deprecated? I'm confused.

[hrg...@gmail.com]

On December 15, 2021 Simeon Vincent wrote:

You can use push messages (either chrome.gcm or the Push API) to wake a service worker.

@Simeon, a question about this, if I may.

The Push API documentation says the following:

For an app to receive push messages, it has to have an active service worker 

Is the MV3 service worker an active worker even after it's shutdown after 5 minutes?

Thanks.

[Simeon Vincent]

Paweł, the extension API is chrome.gcm, but it is powered under the hood by Firebase Cloud Messaging. The references to Google Cloud Messaging in the documentation are out of date and inaccurate. The chrome.gcm API is not being deprecated.

Hrg, I'm pretty sure that the use of "active" in this context is referring to the service worker's lifecycle. A service worker becomes active after it completes the installation phase. At that point, the site (or extension) has an active service worker. If the service worker installation failed during extension installation, there would be no active service worker despite the extension being installed.

Simeon - @dotproto

Chrome Extensions DevRel

[JM Lambert addeective]

I tested it and FCM is indeed waking up the extension ServiceWorker with chrome  96.0.4664.110

Jean-Michel Lambert - addeective.com