Makes sense. I created a PR here https://github.com/w3c/push-api/pull/400.
On Tue, Apr 22, 2025 at 11:32 AM Domenic Denicola <dome...@chromium.org> wrote: > 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/CAOzWxF5v%2BjQDjBBd03uPMXD7A8HYsupfr%3DNV%2BVR_-VW1bzMh5Q%40mail.gmail.com.
