Re: [w3c/push-api] Pass removed subscriptions as a property of the `pushsubscriptionchange` event (#193)

> Also note that we might not actually return `null` in response to `getSubscription()` if we are pre-emptively removing the subscription

Yeah, I think @johnmellor suggested this in https://github.com/w3c/push-api/issues/132#issuecomment-189308012. At that point, a "change" could mean a few things:

1. The subscription is still active, but going away soon. The app should resubscribe soon, and the old subscription will be deactivated once the new subscription is used.
2. The user revoked permission, or the subscription exceeded the background message quota (in Firefox). The app can't resubscribe, but can still notify its server to clean up the old subscription. It's OK if the app ignores this event.
3. The server removed the subscription, the user restored a previously-revoked permission, or reset the quota by visiting the origin again. The app should definitely listen for this event so that it can resubscribe.

I feel like these cases are sufficiently different to where a single event doesn't fit them all. Maybe it's worth thinking about bringing `pushsubscriptionlost` back for case 3, and adding `pushsubscriptiongoing` for case 1.

OTOH, explaining `pushsubscriptionchange` is tricky enough as it is, and adding separate events might make subscription management more complex than it needs to be.

---
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/push-api/issues/193#issuecomment-222090367