Fire pushsubscriptionchange when user revokes permission

[johnmellor]

The spec says, "When a permission is revoked, all push subscriptions created with that permission must be deactivated" (i.e. automatically unsubscribed).

We should clarify in the pushsubscriptionchange section that the pushsubscriptionchange event must be fired in such cases.

This is different from #61 since the webapp's state (cookies, IDB, etc) haven't been reset, and so if we didn't fire pushsubscriptionchange, this would create a new state that sites have to explicitly handle.

(unlike other pushsubscriptionchange events, it won't be possible to resubscribe automatically - but that's fine, because sites already have to handle failure to resubscribe, e.g. in case the device is offline).

[gauntface]

+1 this proposal - it would be a particularly nice UI for developers to handle renewing or maintaining their user account in the pushsubscriptionchange event listener.

[martinthomson]

What ever happened to pushregistrationlost ? That seems like a more appropriate event. Or do we now consider pushsubscriptionchange OK if we subsequently return null to a call to getSubscription()?

[nikhilm]

getSubscription() should probably reject with PermissionDeniedError.

[ghost]

To clarify, this means we should fire pushsubscriptionchange twice, right? Once when permission is revoked, and a second time when it's restored.

So, after revocation, self.pushManager.getSubscription() will resolve to null (per @martinthomson's comment in #150), and subscribe() will reject with PermissionDeniedError. Is that accurate?

Also, if the user restores permission, should the browser automatically resubscribe, or leave it up to the service worker? (Firefox currently leaves it up to the worker, but it might be nice to be explicit about the correct behavior).

Thanks!

[martinthomson]

I think that since we do have the permission API, the simplest (and least-surprising) option would be to have the page check and re-subscribe if the permission is re-granted.

[collimarco]

+1 For triggering a callback when subscription is revoked by the user

This would allow the server to know that a user (for example a user id associated to that endpoint) is no more reachable with push notifications before trying to send them. This allows better handling for providing fallbacks methods (e.g. email). Beside that it allows to determine when a user has unsubscribed and do some analytics. I wrote more extensively about this topic in this blog post.

[ghost]

+1 For triggering a callback when subscription is revoked by the user

I see your point. Firefox only fires pushsubscriptionchange when permission is restored, because the service worker can't resubscribe if permission is revoked...so it didn't really make sense to notify the worker if it couldn't do anything about it.

As you point out, though, the worker can use the event to preemptively remove the old subscription endpoint from its app server, or for analytics.

Your app server will still need to handle the case where the push server drops a subscription without notifying the worker, though. This can happen if the browser isn't connected when the subscription is dropped. The worker will get a pushsubscriptionchange event when the browser is relaunched, but your server will get a 404 if it tries to send a message before then.

[collimarco]

@kitcambridge You've got the point.
If the server has to manage that scenario as an exception is not a problem. However it's an exception, not the normal flow: statistically it would be a great improvement. Moreover I think that most of the time when a user unsubscribes has the browser open and probably is not offline.

However I'm not convinced by the sequence you have described: you say that the token has expired and the push service returns 404 to the application server. That's not possible if the browser is offline. If the user unsubscribes when he's offline neither the push service nor the app server can be informed: they'll be informed at the same time when the user connects to the internet. So I think that you'll never get 404 from the push service for this scenario.

[ghost]

Indeed; the user can't unsubscribe if the browser is closed.

The case I'm talking about is when the push server drops the subscription, without a request from the browser. The server can do this for any reason, at any time: for example, if there are too many outstanding messages for that subscription, if the browser hasn't reconnected in a while, or if the server is running into storage limits.

In that case, the browser will fire a pushsubscriptionchange event the next time it reconnects to the push server. But, until then, sending messages to the dropped subscription will return a 404.

[collimarco]

@kitcambridge Thank you for the clear explanation! Yes, in that case you'll have to manage the 404 as an exception. We are saying the same thing. Indeed in the previous message I've written "you'll never get 404 from the push service for this scenario".

[ghost]

@collimarco You're right. I just misunderstood your first reply. 😄

[beverloo]

Following PR #234, it's now defined that user agents MAY fire the pushsubscriptionchange event when permission is revoked.

Whether we should fire the event when permission is regranted is tracked in #236. I'm still not convinced that should happen in all scenarios.