You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chrome and Windows have moved the exectuion context for windowless extensions from a background page with full DOM APIs to a ServiceWorker. This causes a number of obstacles. Within the SW context, you do not have
window
several APIs jQuery expects
xhr
Additionally, the lifetime of a ServiceWorker has a max length of 5 minutes, even when actively connected. At this point, the entire program is terminated. Not ideal certainly for a persisitent server push connection, but still more reliable within various networks than Firebase push.
So there are two concerns here.
Updates required to the JavaScript library to support the use case
Operational concerns on the server side given the presumed increase of orphaned connections. What are the implications in our situation, going from per user creating a new connection_id per hour vs a new connection_id every 5 minutes.
Note, we aren't using any Scaleout backing planes (we use sticky sessions similar to the suggestions in core) but would have 700k+ concurrent connections we're servicing, so I'm fully interested in any feedback
Expected behavior
(Note, expected is a stretch here). When running SignalR in a manifest v3 extension compared to a manifest v2 extension, there is a slight performance decrease, slight increased cpu usage on the server side, and increased battery usage on the client machine with the increase in needed connections (as opposed to sticking with the already created conncetion).
Any functional impact
Chrome and Windows have moved the exectuion context for windowless extensions from a background page with full DOM APIs to a ServiceWorker. This causes a number of obstacles. Within the SW context, you do not have
Additionally, the lifetime of a ServiceWorker has a max length of 5 minutes, even when actively connected. At this point, the entire program is terminated. Not ideal certainly for a persisitent server push connection, but still more reliable within various networks than Firebase push.
So there are two concerns here.
Note, we aren't using any Scaleout backing planes (we use sticky sessions similar to the suggestions in core) but would have 700k+ concurrent connections we're servicing, so I'm fully interested in any feedback
Expected behavior
(Note, expected is a stretch here). When running SignalR in a manifest v3 extension compared to a manifest v2 extension, there is a slight performance decrease, slight increased cpu usage on the server side, and increased battery usage on the client machine with the increase in needed connections (as opposed to sticking with the already created conncetion).
Actual behavior
SignalR does not work
Steps to reproduce
Service worker registration failed. Status code: 15
andUncaught ReferenceError: window is not defined
The text was updated successfully, but these errors were encountered: