Expose pushManager on Window #393

annevk · 2024-11-19T12:25:23Z

This is part of the Declarative Web Push initiative (see #360) and mainly makes sense when that is supported, although could be independently supported in theory.

This makes window.pushManager work by making push subscriptions tied to a scope rather than a service worker registration. Most often push subscriptions remain 1:1 with service worker registrations, but the scope whose serialized path is "/" is treated specially from now on and can exist independently.

This obsoletes #368.

The following tasks have been completed:

Modified Web platform tests (link to pull request)

Implementer support:

Chromium
Gecko
WebKit

Preview | Diff

This is part of the Declarative Web Push initiative (see #360) and mainly makes sense when that is supported, although could be independently supported in theory. This makes window.pushManager work by making push subscriptions tied to a scope rather than a service worker registration. Most often push subscriptions remain 1:1 with service worker registrations, but the scope whose serialized path is "/" is treated specially from now on and can exist independently. This obsoletes #368.

saschanaz · 2024-11-19T13:06:51Z

@asutherland previously had a strong opinion that notifications should be paired with registration instead of scope in #205, so adding him as a reviewer.

(Although now I see #368 (comment))

This introduces a new feature whereby push messages conforming to a certain JSON format directly create an end user notification and show it (possibly preceded by an enhanced push event). In addition to showing a notification, the app badge can be updated as well. This builds on whatwg/notifications#213 which adds URL members to notifications. Exposing PushManager outside of service workers is handled by #393.

saschanaz

My first round of review. Looks mostly fine but with some questions.

saschanaz · 2025-02-10T13:15:56Z

index.html

-          subscription</a> having the new keys as |newSubscription|.
+          If the <a>user agent</a> has to change the keys of a [=push subscription=] for any reason
+          and the [=push subscription=]'s [=associated service worker registration=] is non-null,
+          it MUST [=refresh=] the [=push subscription=].


(Reviewer note: this change is an editorial refactoring to reuse the term "refresh")

saschanaz · 2025-02-10T13:30:59Z

index.html

          </h2>
          <p>
            A <a>user agent</a> or <a>push service</a> MAY choose to <dfn>refresh</dfn> a <a>push
-            subscription</a> at any time, for example because it has reached a certain age.
+            subscription</a> whose [=associated service worker registration=] is non-null at any
+            time, for example because it has reached a certain age.


Does this mean a subscription without an SWR is never supposed to be refreshed? I think the Firefox push server will keep its logic to auto-clear subscriptions (we do that when an inactive subscription is being spammed and gets a huge amount of message queue). cc @jrconlin

saschanaz · 2025-02-10T13:34:12Z

index.html

        [SecureContext]
-        partial interface ServiceWorkerRegistration {
+        interface mixin PushManagerAttribute {


Sorta weird name when it's a mixin and not an attribute. Bikeshedding: PushManagerBase (kinda following WebGL), PushManagerCommon (kinda following TextDecoder/Encoder), PushManageable (kinda following Animatable), PushManagerSource (kinda following FontFaceSource), PushManagerMixin (kinda following ARIAMixin and PaintTimingMixin), etc etc...

Not strongly against the current name though, especially it's just a spec-only name.

It's a mixin that holds an attribute. Anyway, happy to change to whatever.

saschanaz · 2025-02-10T13:47:46Z

index.html

+        </li>
+        <li>If [=this=] is a {{Window}} object, then set |scope| to the result of running the
+        [=basic URL parser=] given "`/`" and |global|'s <a>associated <code>Document</code></a>'s
+        [=Document/URL=].


This would fail for about:blank, but I guess that's fine as this is restricted to SecureContext.

I think you're correct that there might be some failure scenarios here this needs to account for.

index.html

saschanaz · 2025-02-10T14:21:07Z

index.html

+            </li>
+            <li>If |subscription| is non-null:
+              <ol>
+                <li>If there is an error with |subscription|, then [=queue a global task=] on the


This sentence now sounds like there's an error field on subscriptions, but given the previous sentence was "Let subscription be the result of obtaining registration's push subscription. If there is an error, ..." it was more about an error while obtaining the subscription.

I think either we should throw earlier in the subscription obtaining steps or just remove this step, as the obtaining steps are now clearer and infallible (except the existing null check)?

I think we should keep this as this is not something I was aiming to change in this PR. I'm not really sure how to do it earlier though without getting very verbose.

index.html

saschanaz · 2025-02-10T14:53:42Z

index.html

+            </li>
+            <li>If |subscription| is null, then resolve |promise| with null.
+            </li>
+            <li>If there is an error with |subscription|, reject |promise| with a {{DOMException}}


(Same about error, might be nicer if we throw in the obtaining steps or just skip this. It's unclear what a caller should do if this function throws, so maybe implementations should just pretend that no subscription exists if it's corrupted or something. If there's a good reason to throw error, it would be nice to have a note about that.)

index.html

saschanaz · 2025-02-10T15:09:03Z

index.html

+                <li>If |registration|'s [=associated push subscription=] is non-null, then set
+                |subscription| to |registration|'s [=associated push subscription=].
+                </li>
+                <li>Set |scope| to |registration|'s [=service worker registration/scope URL=].


If the scope URL is the root path then this is also accessible from window, right? I assume that's the intention.

saschanaz · 2025-02-13T10:44:28Z

Neither this PR nor #385 changes the step 2 in section 10.4 Recieving a Push Message:

Let registration be the service worker registration corresponding to the push message.

If registration is not found, abort these steps.

Without changing that I think the window-subscribed push messages would be ignored.

saschanaz · 2025-02-25T13:33:41Z

index.html

+        <p>
+          A [=push subscription=] is considered to have a <dfn for=
+          "push subscription">window-accessible scope</dfn> when its [=push subscription/scope=] is
+          a [=/list=] of [=list/size=] 1 and [=push subscription/scope=][0] is the empty string.


Here the scope seems to be a list of string, but right above it's defined as a URL struct, which looks like a conflict.

Indeed, this should look at the scope's path instead of scope.

This introduces a new feature whereby push messages conforming to a certain JSON format directly create an end user notification and show it (possibly preceded by an enhanced push event). In addition to showing a notification, the app badge can be updated as well. This builds on whatwg/notifications#213 which adds URL members to notifications. Exposing PushManager outside of service workers is handled by #393.

annevk mentioned this pull request Nov 19, 2024

Expose pushManager on Navigator #368

Closed

4 tasks

Update index.html

6e463a7

annevk mentioned this pull request Nov 19, 2024

Declarative Web Push #360

Open

saschanaz requested a review from asutherland November 19, 2024 13:05

annevk mentioned this pull request Dec 5, 2024

Add Declarative Web Push #385

Open

4 tasks

saschanaz reviewed Feb 10, 2025

View reviewed changes

saschanaz reviewed Feb 25, 2025

View reviewed changes

dimitribouniol mentioned this pull request Feb 26, 2025

Declarative Web Push Support mochidev/swift-webpush#66

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Expose pushManager on Window #393

Expose pushManager on Window #393

annevk commented Nov 19, 2024 •

edited by pr-preview bot

Loading

saschanaz commented Nov 19, 2024 •

edited

Loading

saschanaz left a comment

saschanaz Feb 10, 2025

saschanaz Feb 10, 2025

saschanaz Feb 10, 2025

annevk Feb 25, 2025

saschanaz Feb 10, 2025

annevk Feb 25, 2025

saschanaz Feb 10, 2025

annevk Feb 25, 2025

saschanaz Feb 10, 2025

saschanaz Feb 10, 2025

saschanaz commented Feb 13, 2025

saschanaz Feb 25, 2025

annevk Feb 25, 2025

Expose pushManager on Window #393

Are you sure you want to change the base?

Expose pushManager on Window #393

Conversation

annevk commented Nov 19, 2024 • edited by pr-preview bot Loading

saschanaz commented Nov 19, 2024 • edited Loading

saschanaz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saschanaz commented Feb 13, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Nov 19, 2024 •

edited by pr-preview bot

Loading

saschanaz commented Nov 19, 2024 •

edited

Loading