New library for browser (not SW) to handle registration/updates

[jeffposnick]

CC: @gauntface @dfabulich

(This is primarily a placeholder for now, but something to consider for the v4 timeframe.)

Splitting off the conversation from #1120 (comment)

We can add some value by creating a new Workbox module that runs in the browser and elevates this code from a copy-and-paste recipe to a drop-in solution. We can paper over some of the code decisions that a developer would normally have to make by exposing configuration options with sensible defaults.

There's conversation at w3c/ServiceWorker#1222 about making some relevant changes to the spec, in and if that happens, then Workbox could help by providing a polyfill ahead of time. If those spec changes are not actually made, it wouldn't prevent us from creating a new library that accomplishes the same goals, with an interface TBD.

[gauntface]

I do think we could implement something in V4 that could inform the spec if it's slow to move.

[gauntface]

Extra note: Would be good to log info on whether a page is controlled, what it's scope is and what the service worker scope is etc. This is quickly becoming a common question / sticking point for developers. Logging for the developers current situation would be helpful.

[prateekbh]

Question: There is a repetitive question where people are curious on how to show something in browser as soon as new SW kicks in(bringing in new changes to the web app).

Can we use this lib to send out some event may be which app's code can listen to and show a snack-bar or any other UI may be.

[gauntface]

@prateekbh yes thats on the cards - I need to put together a proposal for all this.

[jeffposnick]

Extra note: Would be good to log info on whether a page is controlled, what it's scope is and what the service worker scope is etc. This is quickly becoming a common question / sticking point for developers. Logging for the developers current situation would be helpful.

Maybe we can take this one step further and, in our helper method that wraps registration, refuse to register a service worker whose maximum scope does not include the current page.

In practice, the only times that I've seen developers "legitimately" register a service worker whose scope doesn't include the current page is the push-notification-only service worker use case, where a fake scope within the same origin is used. Developers who need to register those types of service worker could just use the basic navigator.serviceWorker.register() function instead of our wrapper.

[gauntface]

Yeah agree that we can should covered info around the controlled pages.

[jeffposnick]

This is workbox-window, added in v4.