Add Declarative Web Push

[annevk]

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 a new pushnotification 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 will be done in a separate change.

---

The following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementer support:

• Chromium
• Gecko
• WebKit

---

Preview | Diff

[martinthomson]

I'd like to see more explanatory text attached to this sort of change. (In the spec, not the PR, for avoidance of doubt.)

From what I can see, a message is opportunistically parsed as JSON. If it parses and there is a "web_push": 9001 (?!) attribute, the browser attempts to make a notification. If that works, the notification is shown.

There is also a mutable attribute attached, which would allow the SW the option of intercepting the notification and tweaking it before it is shown. That would somewhat negate the benefits from a purely declarative notification, so it seems an unnecessary feature (the app could save the "web_push": 9001 bytes and just make a notification for itself).

[martinthomson]

This seems non-ideal. I don't know how this is supposed to work, but this requires a trap in showNotification to track, but you aren't monkey-patching that. Does preventDefault not work?

[annevk]

I mean, this statement is monkey patching that. Certainly seems reasonable to tidy it up though. (preventDefault() wouldn't guarantee that a notification is shown.)

[martinthomson]

2^63-1. You could say as much and not have people break out a calculator. Is there a constant in the badging part of the API that you can refer to instead?

Second, given that you define the value above with this range, do you need to add this check?

Finally, why? I can't believe that any badging UX will ever show anything that large (most stop after 9 or 99 in my experience).

[annevk]

It's 2^53-1, it specifies the limit in exactly the same fashion as IDL does, and the description of the format doesn't actually come with implementation requirements.

[martinthomson]

Maybe you should double-check that math.

$ python
>>> 2**63-1
9223372036854775807
>>> 2**53-1
9007199254740991

(I don't like argument from precedent, as far as that goes. Especially when it results in long strings of digits like this one.)

[annevk]

Interesting, I wonder why IDL goes beyond max safe integer. Also, I should have used the unsigned variant here so either way this is wrong: https://webidl.spec.whatwg.org/#idl-unsigned-long-long

[beverloo]

As much as I appreciate 9001, we should also consider 8030? (Referring to the Web Push RFC.) Or some number that reflects the collective number of grey hairs we have over this stuff, which is definitely over 9000 😄

[beverloo]

Is there any way in which this can simply match NotificationOptions with a required title and URL? I guess this being JSON makes that difficult? Both the partial selection of available options and the duplication this introduces makes it fragile and more difficult to reason about.

[annevk]

I had a discussion with @domenic in whatwg/infra#642 which will necessitate even more "duplication". At which point I think it's okay that it's slightly differently organized when that makes more sense for the JSON format. I will try to add some explanatory text so it's less confusing.

[beverloo]

There really are three features being added here:

1. Declarative push notifications (w/ the Web Notification API),
2. Declarative push notifications that also fire a JavaScript event,
3. Declarative app badge updating (w/ the Badging API).

I think it'd be helpful to think about them separately. Intuitively I'm in favour of (1) and (3), however I have some concerns about (2).

A large part of our interest in declarative notifications comes from device resource usage improvements that it enables in Web Push message delivery, and from time-to-feedback improvements when users activate a Web Notification.

If the design were to stick to features (1) and (3), it would remove the need to launch a renderer process in Chrome entirely, which brings major savings (& with enough time and determination we could even trim much of our browser process). The mutable property would remove that optimisation, and based on our experience I expect it to be adopted for purposes of (at least) sending analytics pings back to the server. There may be other ways to solve for that use case too.

@beidson describes this as:

We also propose a more flexible event handling model that developers can opt into to transform a push notification. This new model still depends on Service Workers, but provides the privacy-preserving guarantee that there is always a fallback notification to be shown, so pushes cannot trigger silent background runtime.

Existing implementations already solve for this: Chrome shows a default notification on behalf of the website, and IIRC Firefox and Edge penalize and eventually remove the underlying push subscription. I don't understand what benefit this brings over existing functionality.

I propose scoping out this concept from the proposal as it'll need more discussion.