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 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 #393.

---

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.)

[annevk]

Once whatwg/notifications#227 lands this can be checked here instead of showNotification(). Does that seem reasonable? Anything else remaining?

[saschanaz]

Do we have a strong reason to go for snake_case? I find the case is the only deviation from NotificationOptions.

[annevk]

whatwg/infra#642 goes into the high-level thinking behind this. https://w3ctag.github.io/design-principles/#casing-rules has the relevant guideline.

[saschanaz]

(If the casing was same the parsing step could just say "parse it as NotificationOptions" after extracting title first. And then updating notification options wouldn't require updating both specs.)

[annevk]

Right, I did that initially and then based on feedback ended up here.

[saschanaz]

Sorta understandable from infra point but I guess the callers would have to deal with this casing in that case, like:

onpush = async (ev) => {
  // Err, our little cute browser doesn't support declarative web push,
  // so we are here for nice progressive web.
  const { notification } = await ev.data.json();
  
  // This will mostly work until you use requireInteraction.
  // await registration.showNotification(notification.title, notification);
  
  const notificationOptions = {
    ...notification,
    requireInteraction: notification.require_interaction, // 😅
  };
  await registration.showNotification(notification.title, notificationOptions);
};

I wonder it would make sense to have an exception here to prevent extra boilerplate and head-scratching?

[annevk]

I guess we can escalate, but I'm inclined to accept this inconvenience: w3ctag/design-principles#554.

[dimitribouniol]

I'll add that as a server library tracking this proposal, my adoption documentation looks similarly to @saschanaz's, and I'd similarly push for aligning the property names so they could be passed as-is to showNotification(), if only to easy the migration story the community would need to push for to get this adopted:

self.addEventListener('push', function(event) {
    const data = event.data?.json() ?? {};
    event.waitUntil((async () => {
        const notification = data.notification ?? {}
        /// Try parsing the data, otherwise use fallback content. DO NOT skip sending the notification, as you must display one for every push message that is received or your subscription will be dropped.
        const title = notification.title ?? "Your App Name";
        const body = notification.body ?? "New Content Available!";
        
        await self.registration.showNotification(title, { 
            body,
            requireInteraction: notification.require_interaction ?? false,
            ...notification,
        });
    })());
});

[saschanaz]

(If the casing was same the parsing step could just say "parse it as NotificationOptions" after extracting title first. And then updating notification options wouldn't require updating both specs.)

[saschanaz]

Can we split mutable out of this PR for now?

[saschanaz]

Err, is this case sensitive or can we make things consistent?

[annevk]

I'm not familiar with ReSpec.

[hober]

@marcoscaceres, do you know?

[saschanaz]

Sorta understandable from infra point but I guess the callers would have to deal with this casing in that case, like:

onpush = async (ev) => {
  // Err, our little cute browser doesn't support declarative web push,
  // so we are here for nice progressive web.
  const { notification } = await ev.data.json();
  
  // This will mostly work until you use requireInteraction.
  // await registration.showNotification(notification.title, notification);
  
  const notificationOptions = {
    ...notification,
    requireInteraction: notification.require_interaction, // 😅
  };
  await registration.showNotification(notification.title, notificationOptions);
};

I wonder it would make sense to have an exception here to prevent extra boilerplate and head-scratching?

[saschanaz]

Do we know how many existing callers set binary data (arraybuffer/blob etc) here? One can still use base64 though (and Gecko serializes it to base64 anyway).

[annevk]

I don't know, but there should be a variety of workarounds indeed.

[saschanaz]

Noticed during an internal discussion; this would involve cookies as current implemented in Firefox, and clearing site data would mean the cookie jar would become empty, which may be significant if the image URL can only be fetched with proper cookie (imagine an image attachment from a DM). Should we accept such breakage? It seems like that should be somehow covered in the spec at least. (related: whatwg/notifications#5)