[w3c/push-api] Properly defining `pushsubscriptionchange` (#228)

Hi all —

The `pushsubscriptionchange` event ([ref](https://w3c.github.io/push-api/)) is rather poorly defined right now. There are several issues requesting changes and clarifications. I'd like to propose the following semantics for the event.

There are three scenarios in which the browser may want to fire the event.

1. **Subscription invalidation**. This happens when any property of the subscription changes: a new endpoint (expiration and/or refresh) or new encryption keys. The UA should resubscribe on behalf of the developer _before_ firing the event. The old subscription should continue to work until either the new subscription has been used, or a certain period of time passes, e.g. 90 days.
2. **Subscription revocation**. This happens when the UA has dropped the subscription: permission got revoked (#116) or suspended because the website ran out of quota. The website cannot resubscribe in this case.
3. **Subscription lost**. This happens in situations where the UA loses the subscription: database corruption on the PS, or partially on the UA. The UA should attempt to resubscribe on behalf of the developer _before_ firing the event.

Clearing data (#61) is explicitly excluded from scenario (2). We should not inform websites when that happens, even though the application server can still detect this as the push service should reject new messages if/when the unsubscription has propagated. I consider Firefox' invocation when permission is regranted to be equivalent to scenario (3).

I think that we can support these scenarios with the following interface (#132).

The `oldSubscription` attribute (#193) would be NULL in the _subscription lost_ scenario when it's known that there was a subscription, but no complete `PushSubscription` object could be created.

The `newSubscription` attribute would be NULL in the _subscription revocation_ case, as well as in the _subscription lost_ case when resubscribing fails due to insufficient knowledge (i.e. `applicationServerKey`) or networking errors.

```webidl
interface PushSubscriptionChangeEvent : ExtendableEvent {
    readonly attribute PushSubscription? newSubscription;
    readonly attribute PushSubscription? oldSubscription;
};
```

We'll advocate use of [Background Sync](https://wicg.github.io/BackgroundSync/spec/) (#120) for transferring the updated subscription information to the server. This enables us to deal with failed fetches without effectively duplicating that entire specification. Note that Background Sync currently does not support this use-case due to restrictions: it requires a top-level frame in order to register. We'll propose changing the spec.

On a tangent, two changes I'd like to make in Chrome to help developers are (a) issuing a console warning when there's a listener for the `push` event, but not the `pushsubscriptionchange` event, and (b) adding a button to DevTools for manually triggering a `pushsubscriptionchange` event.

Before I go off and update the spec, I'd love your feedback on this :).

/cc @martinthomson @kitcambridge @gauntface

-- 
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/228