Protocol for deploying playground.wp.net incompatible with the previous service worker

[adamziel]

https://github.com/WordPress/wordpress-playground/pull/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:

• Use Playground as that change is rolled out
• Open a new Playground tab while the existing tabs are still active

Since that is a destructive action, let's make sure the new tab asks for permissions, e.g.

New Playground version was just released. You can continue using your current browser tabs, but if you need to open a new tab then Playground will reload ALL your currently open tabs. This will destroy your work in progress on all your temporary sites but won't affect your permanent sites. Would you like to proceed?

cc @dmsnell

[dmsnell]

Seems fine.

[brandonpayton]

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.