Protocol for deploying playground.wp.net incompatible with the previous service worker #566
Labels
Comments
adamziel
added
[Type] Enhancement
adamziel
added a commit
that referenced
this issue
Jun 18, 2023
Removes the entire concept of detecting the service worker version and enforcing an update on mismatch. Auto-reloading the service worker when it's updated thrashes any `postMessage` communication that's in progress at the moment of calling `skipWaiting()`. This causes Playground to hang at the "login" step in #559. However, the browsers handle a lot by default: * `registration.update()` method downloads the new service-worker.js file and compares it byte-by-byte with the existing one * The previous service worker won't die until all the browser tabs it serves are closed * The new service worker will automatically replace the previous one afterwards The only problem remains deploying a website that is backwards–incompatible with the previous service worker. This is tracked separately in #566 Co-authored-by: Dennis Snell <dennis.snell@automattic.com>
adamziel
added a commit
that referenced
this issue
Jun 18, 2023
Removes the entire concept of detecting the service worker version and enforcing an update on mismatch. Auto-reloading the service worker when it's updated thrashes any `postMessage` communication that's in progress at the moment of calling `skipWaiting()`. This causes Playground to hang at the "login" step in #559. However, the browsers handle a lot by default: * `registration.update()` method downloads the new service-worker.js file and compares it byte-by-byte with the existing one * The previous service worker won't die until all the browser tabs it serves are closed * The new service worker will automatically replace the previous one afterwards The only problem remains deploying a website that is backwards–incompatible with the previous service worker. This is tracked separately in #566 Co-authored-by: Dennis Snell <dennis.snell@automattic.com>
|
Seems fine. |
Pookie717
added a commit
to Pookie717/wordpress-playground
that referenced
this issue
Oct 1, 2023
Removes the entire concept of detecting the service worker version and enforcing an update on mismatch. Auto-reloading the service worker when it's updated thrashes any `postMessage` communication that's in progress at the moment of calling `skipWaiting()`. This causes Playground to hang at the "login" step in WordPress/wordpress-playground#559. However, the browsers handle a lot by default: * `registration.update()` method downloads the new service-worker.js file and compares it byte-by-byte with the existing one * The previous service worker won't die until all the browser tabs it serves are closed * The new service worker will automatically replace the previous one afterwards The only problem remains deploying a website that is backwards–incompatible with the previous service worker. This is tracked separately in WordPress/wordpress-playground#566 Co-authored-by: Dennis Snell <dennis.snell@automattic.com>
Open
|
I'm still learning about Service Workers, but it looks like we should be able to address this by using Clients.matchAll() to query for window clients and then use postMessage() to indicate we're asking the user to accept the upgrade. |
|
Let's track this in #1821 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#561 removed auto-refreshing of service workers as it wasn't working as expected and was also destructive.
The only problem remains deploying a website that is backwards–incompatible with the previous service worker.
Most backwards-incompatible changes can be avoided in one way or another.
Those that can't will need to ship with a service worker that forces a one-off
skipWaiting()and reloads all served browser tabs.The latter means reloading work-in-progress tabs for folks who:
Since that is a destructive action, let's make sure the new tab asks for permissions, e.g.
cc @dmsnell
The text was updated successfully, but these errors were encountered: