Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Declarative Web Push #385

Open
wants to merge 11 commits into
base: gh-pages
Choose a base branch
from
Open

Add Declarative Web Push #385

wants to merge 11 commits into from

Conversation

annevk
Copy link
Member

@annevk annevk commented Aug 26, 2024

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

Copy link
Member

@martinthomson martinthomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

index.html Outdated
Comment on lines 1537 to 1521
If a notification has been shown through {{showNotification()}} at this
point, then abort these steps.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Show resolved Hide resolved
index.html Show resolved Hide resolved
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants