Intent to Ship: Push API
Contact emails
joh...@chromium.org, mvanou...@chromium.org, pe...@chromium.org, mlam...@chromium.org (eng)
owe...@chromium.org (PM)
Spec
https://w3c.github.io/push-api/
Summary
This enables developers to send a push message to their Service Worker even after a tab has been closed so they can display a notification and perform additional background tasks such as updating caches.
This intent is for a cohesive subset of the full Push API and we intend to expand our implementation over time as we receive feedback and observe data from users and developers. See limitations section below for more details.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/GLXyXABvA_0/MYPeVxxfGfcJ
Link to demo
https://johnme-gcm.appspot.com/chat/
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, WebView, Android)?
It will initially support everything but WebView. On Android we will only support 4.1 and up, since this feature depends on the Web Notifications API, which in turn depends on notification support introduced in Android 4.1.
Compatibility Risk
Medium to large; this is a new large feature and Chrome is the first to ship it.
We currently require sites to display a Web Notification in response to an incoming message (a notification will be created on the app’s behalf if it fails to do so). This helps ensure they are aware of background execution.
Developers need to specify the "gcm_user_visible_only" key in their Manifest file to indicate that they understand this requirement.
Limitations
1) Chrome’s implementation uses Google Cloud Messaging (GCM) as the push service to which messages have to be pushed by the developer. We participate in the standardization of an app-server to push-service protocol at the IETF, in order to minimize differences between push services from the developer’s perspective.
For now, the site must specify their GCM sender ID (obtained via the Google Developer Console) in their Manifest file using the "gcm_sender_id" key.
2) Due to security concerns, incoming push messages will not yet support payloads. Until we do, developers can use the fetch() method to check the latest state with their server when they receive a push message.
OWP launch tracking bug?
Link to entry on the feature dashboard
I'm grateful that this has been developed with an eye for removing the GCM specific bits and with a credible plan for getting it done. Iteration matters a ton, and I'm also excited the team is committing to that aspect and shipping stable bits now.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
This has been developed in close collaboration with Mozilla. Their requirements have led to many changes, including dropping message bodies.
I'm not aware of public statements regarding implementation status, however. +Sicking
Hi John, this sounds like good stuff!
https://crbug.com/349474 is 403 Forbidden, can you make it public?
I've compared the IDL interfaces in spec and implementation, and the
big difference is PushEvent.data, as you explained. By the way, what
are the security concerns?
The other difference is that the pushsubscriptionchange event is
missing. Will this be implemented, or doesn't it make sense for GCM?
About "gcm_user_visible_only", I tried to follow it in the code and I
think the only effect it has is in
PushMessagingServiceImpl::RegisterFromDocument, where we reach
PUSH_REGISTRATION_STATUS_PERMISSION_DENIED if it's not set. If this is
all it does, it risks becomes de-facto required boilerplate of the
format even though it doesn't do anything. What bad things are
expected to happen if this requirement were removed?
currently require sites to display a Web Notification in response to an incoming message. However we're actively working on also supporting silent push messaging use cases (e.g. syncing without any notification when a shared document was edited remotely). Once we support those, this manifest property will no longer be required (it's there to make sure developers understand the current notification requirement).
Finally, since this is implemented using a Google service (GCM), will
there be any restrictions, quotas or licensing required for non-Google
browsers like Opera for Android? (I know next to nothing about GCM.)
About "gcm_user_visible_only", I tried to follow it in the code and I
think the only effect it has is in
PushMessagingServiceImpl::RegisterFromDocument, where we reach
PUSH_REGISTRATION_STATUS_PERMISSION_DENIED if it's not set. If this is
all it does, it risks becomes de-facto required boilerplate of the
format even though it doesn't do anything. What bad things are
expected to happen if this requirement were removed?I mentioned above that wecurrently require sites to display a Web Notification in response to an incoming message. However we're actively working on also supporting silent push messaging use cases (e.g. syncing without any notification when a shared document was edited remotely). Once we support those, this manifest property will no longer be required (it's there to make sure developers understand the current notification requirement).
On Tue, Feb 10, 2015 at 11:56 PM, John Mellor wrote:I mentioned above that wecurrently require sites to display a Web Notification in response to an incoming message.
Could you elaborate on how this is actually enforced? My understanding is that the push message awakes the service-worker and the ball is passed to js. How is the script enforced to display a notification and not doing something else?
Another thing I'm wondering about is this: if eventually the service-worker will be allowed to do background work, how can we still provide the user control over when and for what extent background networking should happen (letting alone cpu and power use)? I.e. I can imagine a news site wants to amaze me with super fast loading by informing it's service worker every time there is an update which in turn keeps my data connection busy - and potentially burning my money - by pre-caching the new content every once in a while.
On Tue, Feb 10, 2015 at 11:56 PM, 'John Mellor' via blink-dev
<blin...@chromium.org> wrote:
> On 10 February 2015 at 07:46, Philip Jägenstedt <phi...@opera.com> wrote:
>> About "gcm_user_visible_only",
>
> I mentioned above that we
> currently require sites to display a Web Notification in response to an
> incoming message. However we're actively working on also supporting silent
> push messaging use cases (e.g. syncing without any notification when a
> shared document was edited remotely). Once we support those, this manifest
> property will no longer be required (it's there to make sure developers
> understand the current notification requirement).
I don't know, this seems rather odd to me. Will the property continue
to do nothing once it's not required, or will it preserve the current
behavior?
Documentation will come. I'm personally quite unhappy about using the manifest as the place for this extra (temporary) metadata, but Mozilla et al strenuously objected to including an extra object in the API.
The manifest is being spec'd elsewhere and explicitly allows extensions. Not ideal, but it preserves the properties that other vendors have constrained us to uphold.
I really wish it wasn't this way, but these properties, as noted before, will go away in a matter of quarters.
Documentation will come. I'm personally quite unhappy about using the manifest as the place for this extra (temporary) metadata, but Mozilla et al strenuously objected to including an extra object in the API.
The manifest is being spec'd elsewhere and explicitly allows extensions. Not ideal, but it preserves the properties that other vendors have constrained us to uphold.
I really wish it wasn't this way, but these properties, as noted before, will go away in a matter of quarters.
Yes, it is, and the team is moving heaven and earth to make it so, including standardising parts of the protocol between app server and push server that have been purely proprietary until now.
This is the start of a more open push ecosystem, not and endpoint.
Regards