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.
| </li> | ||
| <li> | ||
| <p> | ||
| If |notificationShown| is false, then run the [=notification show steps=] |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
It's not entirely clear to me what you are suggesting here.
There was a problem hiding this comment.
I'm saying that the image fetch step can no longer include cookies when site data is gone and the spec should say something about that.
There was a problem hiding this comment.
Hmm. Isn't that just an artifact from how cookies work as well? Should every specification that potentially fetches something later also point out that cookies currently expire after a little over a year?
There was a problem hiding this comment.
If that spec expects to fetch something without page visit for a long time, maybe? (AFAIK push event is the rare case doing that if not only)
There was a problem hiding this comment.
(But good point, it's not really DWP specific but also affects the existing Push)
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.
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