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

@ShijunS 

> In case a user revokes the permission or the UA revokes the subscription due to violation of the userVisibleOnly setting, it might not be desirable for the user to see a user permission prompt right away.

This is interesting - to my knowledge, currently no browser enables websites to request permission from a Service Worker. Without having a visible foreground tab, how does the user get sufficient context to make a decision?

My thinking with including the `newSubscription` in the event is that it avoids developers from having to call `subscribe()` at all. If they _can_ resubscribe, the UA will already have done so on their behalf.

> Meanwhile, the UA should have some flexibility in firing the event in scenario (2). For example, clearing notification permissions for all sites is fairly close to clearing browsing history from the user experience perspective.

Would it work for you if I phrase the permission revocation scenario with `SHOULD` as opposed to `MUST`? I can see what this may be hard to support architecturally.

I make the assumption that the UA will remove the subscription when permission is revoked, which means that the push service will start rejecting new messages anyway. (Thereby making it observable by the developer.)

> In addition, Re scenario (1), should the event also be fired when the oldSubscription actually expires, maybe with oldSubscription set to "null"?

Since the user agent at least needs to replace the old subscription with the new one, we know there to be an association so presumably it could just read the data of the old subscription prior to removing it?

Some applications store settings and data keyed by the subscription's endpoint to avoid requiring users to log in. It's important for them to be able to migrate such data from the old subscription to the next.

@kitcambridge 

> Making oldSubscription nullable seems a little strange: the browser knows the service worker had a subscription, but can't construct a full PushSubscription object?

Your experiences would actually be really interesting here, actually.

We're seeing two cases in which this is relevant. _(1)_ The UA hasn't connected to the Push Service at all in >9 months, so we _forgot_ about them, and _(2)_ we see a non-negligible amount of file I/O-related database corruptions in the client of our Push Service.

In both cases we know that there used to be a subscription that won't work anymore. In the first case we can provide full data, but in the second case we may only have partial subscription information (usually missing the keys) and the Push Service won't be able to tell the AS that the subscription's gone either.

Admittedly it's an edge-case. If you don't see anything like this right now, I could certainly be convinced to drop it. My thinking here was that the transition from nullable to not-nullable usually is easier than the other way around.

-- 
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#issuecomment-263360675