Re: [w3c/ServiceWorker] Provide a way to skipWaiting when the last tab refreshes (#993)

@dfabulich 

> My imagination is poor, but I don't see how this can happen.

`Content-Disposition` response is one.

> Specifically, the desired behavior is what AppCache does

Appcache allows two versions of the app to run concurrently, assigning caches to documents. So one tab can be running off v2 while another is running on v1. Is this the model you want?

> The point of this diatribe is that it's impossible to reproduce the desired AppCache behavior.

This is why we introduced the client IDs https://jakearchibald.com/2016/service-worker-meeting-notes/#fetch-event-clients, so you can track clients and associate caches with them (via indexeddb or something).

> It's actually pretty tricky for a page to know with confidence how many in-app tabs are still open

The clients API can do this pretty easily.

> If that turns out to be the only long-term way to refresh a page atomically, then this is a big embarrassment for service workers.

This thread is getting pretty long, but I ask that you don't throw around words like "embarrassment", especially as you don't seem so sure about how appcache worked.

What's your favoured solution here? Assigning caches to a particular client, or providing a hook into the refresh button so you can call `skipWaiting` before the fetch is dispatched?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/993#issuecomment-256872917