SW Sample: Registration with Immediate Replacement

[jeffposnick]

It should demonstrate standard registration with a technique for immediately elevating the installing SW to be the controlling SW. (I think this would entail forcing the page to refresh, but it would be good to confirm the best practice first.)

[gauntface]

I think you can force a replacement.

@paullewis had done something similar during our hack day.

[paullewis]

In theory you can use event.replace() in the oninstall callback, but AFAIK that's yet to be implemented. In my case I watch for a waiting service worker and use that to prompt the user to force-refresh, which is less than ideal. If the user has several open tabs to the URL then the SW won't get replaced until all connected clients have disconnected.

[jeffposnick]

Once w3c/ServiceWorker#518 gets implemented (presumably in M41) we should put together this sample. It won't be possible in M40.

[igrigorik]

@jakearchibald just to confirm: w3c/ServiceWorker@c839e33 - that implies that the worker should be able to "take over" (aka, skip waiting) immediately, without any reloads... assuming the correct flag is set. Correct?

[jakearchibald]

Not quite. It's different to installEvent.replace() in a couple of ways:

• It isn't limited to the install event, so you can call it in response to a user action on the page (eg postMessage)
• It doesn't take over pages that were loaded without that registration (eg, first load or shift-reload)

Reloading an uncontrolled page will make it controlled, which can be done with location.reload.

Do you still need imediate take-over of controlled pages? I'm happy to spec that up too, but it felt like two distinct things (see w3c/ServiceWorker#518 (comment))

[igrigorik]

Do you still need imediate take-over of controlled pages? I'm happy to spec that up too, but it felt like two distinct things (see w3c/ServiceWorker#518 (comment))

Yes. At the very least, I want to experiment with it in the context of w3c/ServiceWorker#73 (comment). I can push the controller code ahead of the document, register it as a first thing... and I want it to route all the requests through it on initial load.

[jeffposnick]

Chrome 43 adds support for clients.claim(). That, along with skipWaiting() found in Chrome 42, should be the "official" way of doing this, I believe. No refreshes needed!

I can put something together showing it off in the Chrome 43 timeframe.

[gauntface]

+1 yes please jeff
On 24 Mar 2015 14:46, "Jeffrey Posnick" [email protected] wrote:

Chrome 43 adds support for clients.claim(). That, along with skipWaiting()
found in Chrome 42, should be the "official" way of doing this, I believe.
No refreshes needed!

I can put something together showing it off in the Chrome 43 timeframe.

—
Reply to this email directly or view it on GitHub
#30 (comment).

[TalAter]

I can see cases where the page would have to communicate directly with the just installed ServiceWorker... forcing the page to refresh would seriously hamper the usability of the page.

For example, in my SW library I am creating a script which sites can add to their page, passing the urls of assets to cache as parameters:

<script src="/upup.min.js"></script>
<script>
UpUp.start({
  'content-url': 'offline.html',
  'assets': ['/img/logo.png', '/css/style.css', 'headlines.json']
});
</script>

Since the assets to cache can't be hard coded in the install event, they need to be posted as a message. This leaves the site with two options, either refresh the page (blegh), or only cache content the next time a user visits the page.

I was able to solve this by accessing the ServiceWorker using the ServiceWorkerRegistration object, and posting a message to it directly after install.

I've posted a sample of how this can be done in #94

[jpmedley]

Jeff,

I could have sworn that claim() worked for me in M42. That might just have
been a lack of awareness on my part about canary updates.

Can you please clarify so that I can make sure MDN is correct?

Joe Medley | Technical Writer | [email protected] | 816-678-7195

On Tue, Mar 24, 2015 at 7:46 AM, Jeffrey Posnick [email protected]
wrote:

Chrome 43 adds support for clients.claim(). That, along with skipWaiting()
found in Chrome 42, should be the "official" way of doing this, I believe.
No refreshes needed!

I can put something together showing it off in the Chrome 43 timeframe.

—
Reply to this email directly or view it on GitHub
#30 (comment).

[jeffposnick]

Sorry for the confusion—@jpmedley, you're right that clients.claim() made it into Chrome 42: https://code.google.com/p/chromium/issues/detail?id=450106

I'll add a sample to show off this functionality and close this issue.