Re: [push-api] How to handle service worker unregister? (#121)

> If a user deletes cookies and the service worker is unregistered - how should a developer deal with this?

The next time the user visits the website, it'll be like they're visiting it for the first time, so the developer shouldn't have to do anything special to handle that.

The developer will end up with a stale subscriptionId on their server, which shouldn't be disastrous (this can also occur if the user factory-resets their device, or breaks the device by dropping it, etc). And as you mentioned, push servers may provide ways of cleaning these up, for example GCM replies with [error responses][1] when it knows that a subscriptionId is stale (though that won't help for factory-reset or broken device, as GCM won't know it's stale), and also offers [delivery receipts][2].

> could we add an event to handle this scenario allowing developers to have some opportunity to react?

The event would have to fire *before* cookies are cleared (since, at least in Chrome, clearing cookies also unregisters the Service Worker etc, so there would be nowhere to deliver the event). Might still be useful I guess, but it'd only work if the device happens to be online (since cookies -- and hence all other storage -- are being cleared, the site wouldn't be able to use a one-shot [background sync][3] or similar to notify its server when next online).

[1]: https://developer.android.com/google/gcm/server-ref.html#interpret-downstream
[2]: https://developer.android.com/google/gcm/ccs.html#receipts
[3]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/121#issuecomment-77148721