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

@wanderview I think I haven't been clear enough in my explanation, so I've provided a clearer statement of the bug in the initial description, now with a code sample, steps to reproduce, expected behavior, and actual behavior.

Specifically, the desired behavior is what AppCache does, so I know it must be _possible_.

>> In my view, that's exactly what refreshing is: it's a navigation away, followed immediately by a navigation back to the current page.
>This isn't really accurate.

I know; I've read all about it. But it works perfectly in AppCache. That's the behavior I want.

> Given that `update()` must be called to get the SW before the refresh navigation I think pages should probably just build their own "check for updates" and "update found, click to reload" buttons. I suppose devtools could also have those buttons for the site.

I think this is a misunderstanding about what I want. As I explained above, in AppCache, when the manifest updates, the _first_ refresh gets stale content, as expected/desired. The AppCache re-installs itself in the background, so the _second_ post-install refresh "just works."

I agree that there's no good way to make the _first_ refresh update the service worker, but subsequent refreshes should just work. The refreshed page's navigation should simply be paused while the initial page unloads and the new service worker activates.

I could imagine a simple API like: `self.activateOnLastRefresh();` that you could call on `install` that would do what I want.

Except, not really, because that should just be the default. If anything, if anybody wants to opt into this buggy behavior, _they_ should be calling an API like, `self.yieldToPreviousWorker()`.

And, to be clear, the proposal to build an in-app update UI is really not a good one. It's actually pretty tricky for a page to know with confidence how many in-app tabs are still open, especially since there's no way to add a lock/semaphore on this.

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.

Back in 2012, @jakearchibald wrote that infamous article, http://alistapart.com/article/application-cache-is-a-douchebag

As a "game" app, I guess I won the AppCache lottery or something, because AppCache was pretty straightforward. I had to set `NETWORK: *` and I had to add a version comment to the manifest, but other than that, I tell you, it just worked.

This bug is douchier than anything AppCache ever did to me.

-- 
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-255489429