Intent to Implement and Ship: Push userVisible and hasPermission()

[Peter Beverloo]

Contact emails

pe...@chromium.org, mig...@chromium.org

Spec

https://w3c.github.io/push-api/#pushsubscriptionoptions-dictionary

https://w3c.github.io/push-api/#pushmanager-interface

Summary

Chrome currently supports the Push API, but requires developers to display a Web Notification in response to incoming messages. This is done by enforcing the existence of a “gcm_user_visible_only” key in the site’s manifest file.

This is a proprietary and prefixed solution, which was discussed in our previous Intent to Ship. Additionally, because we cannot access the manifest from within Service Workers, right now we have to assume that the developer’s intent is to only send push messages resulting in user visible UI.

We have introduced an optional dictionary having a “userVisible” key to the subscribe() method through which the developer can clarify their intent.

This key also allows us to explain the hasPermission() method accurately, which we therefore would like to ship.

Example

serviceWorkerRegistration.pushManager.subscribe({

    userVisible: true

}).then(...);

serviceWorkerRegistration.pushManager.hasPermission().then(...);

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

Yes - minus Android WebView because we don’t support the Push API there.

Compatibility Risk

Small. We are the only ones who ship the Push API, and this is a specified iteration on our implementation. Implementations which do not care about the value of userVisible will ignore it.

The Permission API already supports this option in the Push permission descriptor. We acknowledge that the hasPermission() method presents some overlap for this API, but consider this to be OK because (1) the API footprint is very small, and (2) it allows existing users of Push to avoid introducing a dependency on the Permission API, which other UAs could choose to deliver independently of Push.

We plan to deprecate the “gcm_user_visible_only” manifest key and will show a warning in the developer console when this is used, but not the userVisible key. Chrome 45 will remove support for the manifest key altogether.

OWP launch tracking bug?

https://crbug.com/471534

Link to entry on the feature dashboard

None.

[Anne van Kesteren]

On Fri, Apr 17, 2015 at 4:28 PM, Peter Beverloo <pe...@chromium.org> wrote:
> serviceWorkerRegistration.pushManager.hasPermission().then(...);

It seems weird for this API to not return a boolean while being called
hasPermission(). Shouldn't it be named similar to what we have for
notifications but instead be a method as it returns a fresh promise?
I.e. permission()?


--
https://annevankesteren.nl/

[Michael van Ouwerkerk]

Anne, let's discuss the method name in this spec issue: https://github.com/w3c/push-api/issues/136

/m

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Beverloo]

We'll pursue the name change in the issue Michael referred to. Further feedback is most welcome of course.

I've filed an entry on the feature dashboard as well:

  https://www.chromestatus.com/feature/5778950739460096

Thanks,

Peter

[Chris Harrelson]

userVisibleOnly sounds more clear to me. LGTM modulo that feedback.

[Philip Jägenstedt]

LGTM2. It looks like discussions in https://github.com/w3c/push-api/issues/136 and https://github.com/slightlyoff/BackgroundSync/issues/39 are both ongoing, but it would be best if they were resolved by the people closest to the spec. If it remains in limbo so that there's a risk of this slipping a release, maybe ping this thread again.

Philip

[Michael van Ouwerkerk]

An update on the naming: hasPermission() became permissionState() [1] and userVisible became userVisibleOnly [2].

[1] http://w3c.github.io/push-api/#widl-PushManager-permissionState-Promise-PushPermissionState--PushSubscriptionOptions-options

[2] http://w3c.github.io/push-api/#widl-PushSubscriptionOptions-userVisibleOnly

Regards,

Michael

[Peter Beverloo]

Miguel has since been landing the patches for propagating the rename in Blink and Chromium. Thank you for the feedback!

Are there any further concerns from the API owners? This Intent is still low one LGTM as well.

Thanks,

Peter

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google

[Peter Beverloo]

Thank you!

I received some off-list feedback from Philip regarding this intent. Mozilla can live with the permissionState() name, and are, as expected, not impacted by the userVisible -> userVisibleOnly rename.

We'll go ahead and land the final few CLs now :-).

Thanks,

Peter