Intent to Prototype: Pushsubscriptionchange event upon resubscription

[Antonio Sartori]

Contact emails

antonio...@chromium.org

Explainer

None

Specification

https://w3c.github.io/push-api/#the-pushsubscriptionchange-event

Summary

Fire the pushsubscriptionchange event in service workers when an origin for which a push subscription existed in the past, but which was revoked because of a permission change (from granted to deny/default), is re-granted notification permission. The event will be fired with an empty oldSubscription and newSubscription.

Blink component

Blink>PushAPI

Motivation

This change is helpful for web developers and for users. On the one hand, when regranting notification permissions, used are likely to expect to start receiving again notifications right away. On the other hand, web developers must basically keep trying resubscribing to notifications in order to recover from a permission being ungranted and then granted again. The specification supports the pushsubscriptionchange event, although is relatively vague around the exact circumstances in which such event may or should be fired.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1497429) Firefox seems to already implement a similar behavior, see https://bugzilla.mozilla.org/show_bug.cgi?id=1497429

WebKit: No signal Seems shipped, but couldn't figure out the exact details. See https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/pushsubscriptionchange_event

Web developers: No signals Likely positive, see for example https://issues.chromium.org/issues/40129474

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/407523313

Launch bug

https://launch.corp.google.com/launch/4390563

Estimated milestones

M137

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5147683423256576?gate=6273678305918976

This intent message was generated by Chrome Platform Status.

[Peter Beverloo]

Hi Antonio,

Thank you for working on this - this is a great change: especially on Android it's very easy for users to accidentally disable, and then immediately re-enable notification permission, without realising that they have to visit the site again in order to continue receiving notifications. This creates a convenient recovery path in the way the spec intended.

We should monitor whether we could safely create a new subscription internally and pass it to the `pushsubscriptionchange` event, but as you mention it's not entirely clear what existing implementations of the event do. Manually creating a new subscription is safe in either scenario, and forward compatible with passing in one ourselves as `subscribe()` is designed to be called any number of times.

Thanks,
Peter

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF6xvYb-0qkPaZbhNFuS86__DEg8curFPGRtuDak8x%3D31g%40mail.gmail.com.

[Kagami Rosylight]

The implementation statuses here are mostly based on assumption, can we have some test case to verify that? Especially when Peter is here who's known with his great test pages 💜 (https://tests.peter.sh/)

[Kagami Rosylight]

(I can also go ahead and update WPT in https://phabricator.services.mozilla.com/D234718 to verify, but WPT support is very limited in terms of Push API)