Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Push events should Soft Update service worker #115

Closed
johnmellor opened this issue Feb 19, 2015 · 6 comments
Closed

Push events should Soft Update service worker #115

johnmellor opened this issue Feb 19, 2015 · 6 comments

Comments

@johnmellor
Copy link
Contributor

Incoming push events should trigger the Service Worker's Soft Update algorithm (currently only triggered by top-level page loads), to allow a Service Worker used only in the background to receive push events (and perhaps show notifications) to update itself.

The Soft Update should occur even if the event fails (event handler throws an exception, or rejects the event.waitUntil promise), as it's in such situations that it might be particularly urgent to update the Service Worker.

@johnmellor
Copy link
Contributor Author

@jakearchibald

@jakearchibald
Copy link
Contributor

Agreed, specs that extend ServiceWorker should be free to do this.

Is there any concern about this using up peoples' data? It feels more sensitive because there's no user trigger. Is it worth applying some kind of throttle to the update checks from background events? Either based on time since last soft update, or disable on cellular-based connection types.

Ideally a SW update check should mostly be an etag-based conditional request and a 304 response, but a badly built site could, for whatever reason, put a timestamp in their SW and update a large cache per update.

Although, to be fair, native apps update in the background and pull down megabytes of stuff.

+@jungkees

@mfalken
Copy link
Member

mfalken commented May 20, 2015

Also worth pointing out Soft Update doesn't necessarily bypass the browser cache, that only happens if 24 hours elapsed since the last Update. So maybe we don't have to worry much about data?

@martinthomson
Copy link
Member

Soft update in this case might be inadvisable, unless certain other triggers are hit. In cases where the push event is handled without additional network activity, a mobile device might not fire up the radio. Forcing this check would result in radio activation, which is a hugely battery intensive activity.

Perhaps this can instead be conditional on the first fetch being made in response to the push.

@mfalken
Copy link
Member

mfalken commented Aug 5, 2015

This issue is obsoleted by w3c/ServiceWorker#514 which defines generically when to update service workers in response to events.

@martinthomson
Copy link
Member

We don't need this, we need to remove our references to it instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants