v138 · miscellaneous

Pushsubscriptionchange event upon resubscription

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.

concepts

  1. Resubscribe Event

    pushsubscriptionchange now fires on automatic resubscription, not just unsubscribe. Sites can re-sync server-side endpoints when the browser rotates keys.

  2. Server-sync flow

    Three-actor dance — SW, push service, backend — with stale-endpoint detection. The exact silent-rotation bug 138 closes, made visible.

  3. Subscription Lifecycle

    Clickable state machine covering every transition: no subscription → active → revoked → resubscribed. Includes an event log simulator showing exactly which service worker events fire (and didn't before Chrome 138).

  4. Endpoint migration tool

    Step through the full subscription rotation lifecycle: old endpoint → pushsubscriptionchange fires → server receives new subscription → stale endpoint purged. Shows before-and-after of the silent-rotation bug Chrome 138 closes, with a side-by-side of the broken vs fixed server sync flow.

why it shipped

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.

references