Add Declarative Web Push #385
Conversation
There was a problem hiding this comment.
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
| If a notification has been shown through {{showNotification()}} at this | ||
| point, then abort these steps. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
Once whatwg/notifications#227 lands this can be checked here instead of showNotification(). Does that seem reasonable? Anything else remaining?
annevk
force-pushed
the
declarative-push
branch
from
7b3b218 to
4f6bd92
Compare
annevk
force-pushed
the
declarative-push
branch
from
d6af68d to
56c5432
Compare
| @@ -56,7 +56,8 @@ | |||
| }; | |||
| </script> | |||
| </head> | |||
| <body data-cite="service-workers FILEAPI secure-contexts hr-time permissions ECMASCRIPT"> | |||
| <body data-cite= | |||
| "service-workers FILEAPI secure-contexts hr-time permissions ECMASCRIPT NOTIFICATIONS BADGING"> | |||
There was a problem hiding this comment.
Err, is this case sensitive or can we make things consistent?
There was a problem hiding this comment.
I'm not familiar with ReSpec.
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.
| <li> | ||
| <p> | ||
| If |appBadgeSet| is false, then <a href= | ||
| "https://github.com/w3c/badging/issues/111">w3c/badging #111</a>... |
| </li> | ||
| <li> | ||
| <p> | ||
| Let |declarativeResult| be the result of running the [=/declarative push message |
There was a problem hiding this comment.
This happens after "If |registration| is not found, abort these steps." step above. Either #393 or this PR should fix that.
| <li> | ||
| <p> | ||
| If |declarativeResult|'s [=declarative push message parser result/mutable=] | ||
| is true: |
There was a problem hiding this comment.
Probably should check the existence of registration too?
| <li> | ||
| <p> | ||
| <a>Fire a functional event</a> named "`push`" using <a>PushEvent</a> on | ||
| |registration| with the following properties: | ||
| </p> | ||
| <dl> | ||
| <dt> | ||
| `data` | ||
| {{PushEvent//data}} |
There was a problem hiding this comment.
| {{PushEvent//data}} | |
| {{PushEvent/data}} |
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:
Implementer support:
Preview | Diff