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.)
On Tue, Apr 22, 2025 at 6:24 PM Antonio Sartori <antoniosart...@chromium.org> wrote: > (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) > > On Tue, Apr 22, 2025 at 11:17 AM Antonio Sartori < > antoniosart...@google.com> wrote: > >> 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. >> >> On Tue, Apr 22, 2025 at 11:07 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> >>> >>> On Thursday, April 17, 2025 at 5:44:29 PM UTC+9 Chromestatus wrote: >>> >>> Contact emails antoniosart...@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? >>> >>> >>> >>> >>> Blink component Blink>PushAPI >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPushAPI%22> >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? 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 >>> <https://chromestatus.com>. >>> >>> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8YGJK%2BhPokJ8dv0F9sC6cYD9H%3Dm-b7B7Ti32CZFR2ikg%40mail.gmail.com.
