Intent to Implement and Ship: PushSubscription.options

[John Mellor]

Contact emails

joh...@chromium.org

Spec

https://w3c.github.io/push-api/#idl-def-PushSubscription

(minor update not worth TAG review)

Summary

An "options" attribute is added to the PushSubscription objects that the PushManager.subscribe(...) and getSubscription() promises resolve to. It reflects the options passed in by the author when the subscription was subscribed.

Motivation

This allows web developers to see what applicationServerKey each subscription is associated with, and hence what key their server will need to present when sending messages. Previously web developers with more than once applicationServerKey had to keep track of this separately (e.g. in IndexedDB).

Interoperability and risk

Firefox: The attribute was proposed by Mozilla, added to the spec, and they already shipped it in Firefox 48 beta. Currently they only implement the applicationServerKey attribute of the PushSubscriptionOptions interface, but omit the userVisibleOnly attribute, since Firefox ignores that flag.

Edge: No public signals Safari: No public signals Web developers: No signals

Compatibility risk

Zero - this just adds a new attribute and interface.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, except Android WebView which doesn't yet support the Push API.

OWP launch tracking bug

None. Implementation bug: https://crbug.com/626627

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5678199010754560

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

LGTM1, but I wonder about the timing. getSubscription says "Return promise and continue the following steps asynchronously." and then "If the Service Worker is not subscribed, resolve promise with null." I can't tell if calling getSubscription() immediately after subscribe() should always resolve with a PushSubscription object, always null, or if it's racy? Maybe a simpler design would be for getSubscription() to be sync and to say that it will start returning a non-null value right before the subscribe() promise is resolved?

(Also note that the “Intent to Implement” template has an Interoperability and Compatibility Risk section that is also about how we might regret shipping the feature later, if we fail to reach interop. Given that Firefox has shipped this is looking good though.)

[John Mellor]

> I can't tell if calling getSubscription() immediately after subscribe() should always resolve with a PushSubscription object, always null, or if it's racy? Maybe a simpler design would be for getSubscription() to be sync and to say that it will start returning a non-null value right before the subscribe() promise is resolved?

There's no real use case for calling getSubscription() immediately after subscribe(), since the subscribe promise is resolved with a PushSubscription object, same as getSubscription. getSubscription() is mainly used after a new page load, to find out whether the user is already subscribed; such a call needs to be async since the subscriptions are stored in the browser process (and we'd rather neither use a sync IPC nor slow down renderer startup by fetching the subscription then).

To clarify though, PushSubscription objects have been shipped this way since m42 - this intent is just about adding the "options" attribute to them.

> the “Intent to Implement” template has an Interoperability and Compatibility Risk section that is also about how we might regret shipping the feature later, if we fail to reach interop.

The worst case is that we keep having to store and expose these values. Not a big cost.

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

On Fri, Jul 8, 2016 at 4:53 PM John Mellor <joh...@chromium.org> wrote:

> I can't tell if calling getSubscription() immediately after subscribe() should always resolve with a PushSubscription object, always null, or if it's racy? Maybe a simpler design would be for getSubscription() to be sync and to say that it will start returning a non-null value right before the subscribe() promise is resolved?

There's no real use case for calling getSubscription() immediately after subscribe(), since the subscribe promise is resolved with a PushSubscription object, same as getSubscription. getSubscription() is mainly used after a new page load, to find out whether the user is already subscribed; such a call needs to be async since the subscriptions are stored in the browser process (and we'd rather neither use a sync IPC nor slow down renderer startup by fetching the subscription then).

To clarify though, PushSubscription objects have been shipped this way since m42 - this intent is just about adding the "options" attribute to them.

Even if there's no use case, will the behavior of getSubscription() immediately after subscribe() be reliable as implemented, and is that reliable behavior required by the spec? (If both are implemented on the browser process and subscribe() is handled synchronously in the IPC message, then it seems like there is a simple guarantee that can be made.)

[John Mellor]

No, calling getSubscription immediately after subscribe will race, and since new subscriptions require a network request, getSubscription will often win the race and return null. The spec seems to allow that. Conceptually, the new subscription is only guaranteed to exist once we resolve the subscribe promise. Is this kind of race not typical for async promise APIs?

[Philip Jägenstedt]

Yes, I suppose that the order of promise fulfillment is left undefined more often than not, and that races are common. I was just thinking that if one does something user-visible with the result of getSubscription() (in a different part of the code than where subscribe() is called) then one may end up showing the wrong state. But then I guess the pushsubscriptionchange event will fire moments later.

But none of this has anything to do with the added options, sorry for digressing.

[Rick Byers]

LGTM3