Intent to Implement and Ship: Push API : Allow passing a base64url-encoded value to `applicationServerKey`

[Hwanseung Lee]

Contact emails hs121...@samsung.com, pe...@chromium.org Spec https://w3c.github.io/push-api/#idl-def-pushsubscriptionoptionsinit Summary The applicationServerKey option is used by the user agent when establishing a push subscription with a push service.

This is the key that the application server will use to authenticate itself when sending push messages to this push subscription. applicationServerKey only supports BufferSource in currently Chrome. after this change, it can also accept a base64url encoded value. Motivation

The applicationServerKey is currently specified as a BufferSource.

We could be a little more flexible in terms of how we allow applications to set this value.

Interoperability risk Firefox: Shipped - https://bugzilla.mozilla.org/show_bug.cgi?id=1337348
Edge: No public signals Safari: No public signals Web developers: Positive - https://bugs.chromium.org/p/chromium/issues/detail?id=802280 Compatibility risk there is no compatibility risk. because it is just allow to passing base64url encoded value additionally. Ongoing technical constraints None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes - minus Android WebView, because we don’t support the Push API there. OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=802280 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5242984710799360 Requesting approval to ship? Yes

[Philip Jägenstedt]

This seems pretty straightforward if Firefox has already shipped it. Can you please also comment on this part of Intent to Ship template?

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

• A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

• A spec issue for some change that would make it possible to test. (example)

• A Chromium issue to upstream some existing tests. (example)

An Intent to Ship requires either a web platform test suite or such issues to be filed explaining why such a test suite is currently impossible or in the progress of being upstreamed.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3270d25-e31d-449e-8f69-67c98484424d%40chromium.org.

[Peter Beverloo]

Thanks for sending this, Hwanseung Lee!

Including Push API related behaviour as part of Web Platform Tests is covered by the following issue:

https://github.com/w3c/web-platform-tests/issues/5630

Testing that passing certain values to the `applicationServerKey` property throws certain exceptions is an option. While such tests would have to be very narrowly scoped to avoid requiring user permission, which isn't possible yet either, one test to consider is verifying that base64url-encoded strings are accepted, while base64-encoded strings are not.

That said, I think that we'd like to contribute to a more comprehensive test suite anyway once we can write WPT tests for the Push API, so don't have strong feelings on whether we should block on such an addition.

Thanks,

Peter

[Philip Jägenstedt]

I would say that the min bar is idlharness.js tests, since those won't change if automation capabilities improve. But note that dictionary members aren't exercised, so it doesn't really help for `applicationServerKey`.

Testing that the PushSubscriptionOptions constructor doesn't throw an exception would provide some value, but let's leave that to the code reviews to judge, depending on the details it might also be silly.

LGTM1 with as many shared tests as seems valuable without solving the bigger testing problem.

On testing the Push API more generally:

Permission automation is on our roadmap, but I suspect just that won't be enough to get much further.

Per https://caniuse.com/#feat=push-api, Edge just got support and Safari doesn't have it yet, so now, before it's supported everywhere and the interop problems get worked around with libraries, is a great opportunity to ensure the future interop of the feature.

I think the next step for https://github.com/w3c/web-platform-tests/issues/5630 is to outline a draft WebDriver API and get feedback from other vendors. https://github.com/w3c/sensors/issues/363 is a great example of this currently in progress.

HTH, and happy testing!

[Chris Harrelson]

LGTM2 with the same conditions as what Philip mentioned.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYezOhmYSoGoOKXcMBGz-XTODDCO0SaQ%3DwAmH7TF-Dv0YA%40mail.gmail.com.

[Rick Byers]

LGTM3 - yes please block shipping on landing web-platform-tests for anything useful which can be automatically tested (like constructor behavior).

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYezOhmYSoGoOKXcMBGz-XTODDCO0SaQ%3DwAmH7TF-Dv0YA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9Bebz3sM%2B%3DM_NqD6CASVvcryrUHVHm9vDoxX0dYSzCtw%40mail.gmail.com.