Intent to Ship: Pushsubscriptionchange event upon resubscription

[Chromestatus]

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

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

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

No

Flag name on about://flags

None

Finch feature name

PushSubscriptionChangeEventOnResubscribe

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

Shipping on desktop	137
Shipping on Android	137

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF6xvYb-0qkPaZbhNFuS86__DEg8curFPGRtuDak8x%3D31g%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1. Are you able to clarify which platforms this isn't shipping on? Presumably iOS?

[Antonio Sartori]

Thanks!

Yes, this isn't shipping on iOS. Moreover, this does not really apply to Android WebView, where the whole Web Push API is not enabled. I clarified it in the appropriate field.

[Domenic Denicola]

On Thursday, April 17, 2025 at 5:44:29 PM UTC+9 Chromestatus wrote:

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.

I can't find any spec text that ever fires a pushsubscriptionchange event with "empty oldSubscription and newSubscription". (Does that mean null? Or is there a special concept of an empty `PushSubscription` object?)

Can you help explain me find where this behavior is specified?

[Antonio Sartori]

That is correct, the spec never explicitly fires a pushsubscriptionchange event with "empty oldSubscription and newSubscription". The spec mandates ("MUST") firing the event on a subscription refresh (which chrome never does). In the security and privacy considerations, it allows ("MAY") firing the event on a permission revocation (When a permission is revoked, the user agent MAY fire the "pushsubscriptionchange" event).

I was reading the explanation of the event itself:

"The pushsubscriptionchange event indicates a change in a push subscription that was triggered outside of the application's control, for example because it has been refreshed, revoked or lost."

together with the fact that the permission change happens outside of the application's control, as a justification for triggering the event. But I agree that this is probably stretching the interpretation a bit. I will try to explore clarifying this in the spec.

[Antonio Sartori]

(However, the spec does seem to allow both oldSubscription and newSubscription to be null, at least that is what I would read out of https://w3c.github.io/push-api/#pushsubscriptionchangeeventinit-interface)

[Domenic Denicola]

Sure, those values are in the possible value space. But it'd be good to see some text that explicitly fires an event with them both set to null. Right now no spec text does so, and thus it wouldn't be spec-conformant to fire such an event. (Just like there's no spec text for firing a hashchange event with oldURL = newURL = "asdf", even though that's in the value space of USVString.)

[Antonio Sartori]

Makes sense. I created a PR here https://github.com/w3c/push-api/pull/400.

[Yoav Weiss (@Shopify)]

LGTM2

Thanks for sending the PR. Please make sure it lands, but it's not a blocker for shipping IMO.

[Daniel Bratell]

LGTM3

/Daniel

--
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/055b7d47-4e6a-46e2-8443-3f5aeac973dcn%40chromium.org.