Firing `pushsubscriptionchange` when permission is regranted

[beverloo]

Firefox currently fires pushsubscriptionchange when an origin gets permission regranted.

We are considering doing the same in a slightly different scenario; some operating systems enable users to disable entire applications (i.e. the browser) from showing notifications. Since we still tie push to notifications, it may not make sense to continue receiving messages in this scenario. When the user allows the application to show notifications again, suspended subscriptions should be able to be reinstated.

I don't think it's a good idea to specify the specific circumstances under which this can happen. Rather, we need to make sure that the language we have allows for these use-cases.

/cc @kitcambridge

[shehi]

4 years passed. Crossing fingers for the 5th... :)

[saschanaz]

Blink just posted intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/BYoV9Zrn6Os/m/0l4NTg2jAgAJ

Would be nice to update the spec if we want to proceed here.

[collimarco]

@saschanaz Why the spec needs to be updated? We have been using the pushsubscriptionchange event for years (here you can see the code: https://pushpad.xyz/blog/web-push-error-410-the-push-subscription-has-expired-or-the-user-has-unsubscribed). Please don't make unnecessary breaking changes. The current pushsubscriptionchange event already supports the possibility to have only the new subscription (in case the old one is no longer available).

[saschanaz]

It's about firing this event for the additional case. If we want to make it work for all browsers then it should be specified. I don't think such change would be a breaking change.

[antosart]

I've drafted #400 to explicitly allow firing the pushsubscriptionchange event in more cases.