Intent to Ship: Notification Inline Replies

[Anita Woodruff]

Contact emails

aw...@chromium.org, nsat...@chromium.org, pe...@chromium.org

Explainer

https://github.com/anitawoodruff/inline-notification-replies

Spec

https://github.com/whatwg/notifications/ - see https://github.com/whatwg/notifications/pull/132 for the specific additions.

TAG review: w3ctag/design-reviews#284

Summary

An addition to the Notifications API to allow users to type a text reply to a notification within the notification's own UI.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/9s8Zamqbv34/JngoiqKeAwAJ

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

Android N +, Windows 10 + (with native notifications enabled) and Chrome OS.

Older versions of Windows to follow, but not planned on Linux and Mac OS.

Not supported on WebView because WebView does not yet support notifications.

Demo link

https://tests.peter.sh/notification-generator/ - select an action with type 'text' from the dropdown of example actions (currently requires enable-experimental-web-platform-features to be set in chrome://flags). Select 'Show an alert' under Reaction Settings to check the reply.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

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

I created https://github.com/web-platform-tests/wpt/pull/11122 to test the new interface properties, currently blocked on https://github.com/web-platform-tests/wpt/issues/11105 (infra bug)

Fuller testing of the Notifications API is blocked on adding an Automation section to the Notifications API - see https://github.com/whatwg/notifications/issues/134

Entry on the feature dashboard

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

[Joe Medley]

The Bug Url field on Chrome Status is intended for a Chromium tracking bug so that interested parties can follow the work. Do you have one?

Your whatwg issue can go in the Documentation field.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

[Yoav Weiss]

On Sat, Jun 23, 2018 at 12:55 AM Anita Woodruff <aw...@chromium.org> wrote:

Contact emails

aw...@chromium.org, nsat...@chromium.org, pe...@chromium.org

Explainer

https://github.com/anitawoodruff/inline-notification-replies

Spec

https://github.com/whatwg/notifications/ - see https://github.com/whatwg/notifications/pull/132 for the specific additions.

TAG review: w3ctag/design-reviews#284

Summary

An addition to the Notifications API to allow users to type a text reply to a notification within the notification's own UI.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/9s8Zamqbv34/JngoiqKeAwAJ

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

Android N +, Windows 10 + (with native notifications enabled) and Chrome OS.

Older versions of Windows to follow, but not planned on Linux and Mac OS.

Not supported on WebView because WebView does not yet support notifications.

Demo link

https://tests.peter.sh/notification-generator/ - select an action with type 'text' from the dropdown of example actions (currently requires enable-experimental-web-platform-features to be set in chrome://flags). Select 'Show an alert' under Reaction Settings to check the reply.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

Did you try to reach out to other vendors? 

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

I created https://github.com/web-platform-tests/wpt/pull/11122 to test the new interface properties, currently blocked on https://github.com/web-platform-tests/wpt/issues/11105 (infra bug)

Fuller testing of the Notifications API is blocked on adding an Automation section to the Notifications API - see https://github.com/whatwg/notifications/issues/134

Entry on the feature dashboard

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

--

[Daniel Bratell]

This sounds like a good addition to the notification feature, but I'm also missing feedback from other vendors on either the specification or in a reported feature request. Without that it there is the risk it might end up being a feature that web developers can't rely on, or a feature that will have incompatible implementations.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Anita Woodruff]

Update:

TAG review is now complete (https://github.com/w3ctag/design-reviews/issues/284) and

we are waiting to hear back from other browser vendors - I have reached out to them on the

spec pull request here.

Given the limited API surface of this change compared to the capability it enables, as well as the

fact that developers have the means to feature detect support, we think this is a low-risk change 

that'd be great to include in M69. 

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

[Christopher Thompson]

I'm glad you included a note to user agents that they must identify the origin of the notification. While I'm less immediately worried about these notifications being used for phishing, we have been worried about other abuse in the past. Chrome has had some attempts at designing solutions to the abuse problem in the past, but they never shipped. Notifications are a particularly common target for abuse, and adding more powerful features to them means we want to keep an eye on that (from the Chrome side, that means we may want to try to revive those anti-abuse efforts). User agents would also want to be sure that this origin display behaves well under adversarial conditions (such as correctly eliding very long origins to maximize user understanding).

Would this new part of the notifications API be limited to secure contexts? (I wasn't able to find mention either way looking at the spec diff.) If not, attributing the origin may not be the most useful mitigation (our general concern with powerful API features).

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--

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/55579a7b-c43f-4caa-8651-5a875a513dab%40chromium.org.

[Anita Woodruff]

Would this new part of the notifications API be limited to secure contexts? 

Yes, since inline replies require use of an action button, and actions are already restricted to secure contexts, as they can only be used when showing notifications from a service worker.

(See Step 3 of https://notifications.spec.whatwg.org/#create-a-notification - "If a serviceWorkerRegistration was not provided and options’s actions is not empty, throw a TypeError exception.")

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Christopher Thompson]

Thanks for the clarification. I think that was my only concern from a spec-perspective.

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
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/55579a7b-c43f-4caa-8651-5a875a513dab%40chromium.org.

--
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/10ca02cb-c29b-40fd-b13a-cf081337f7ca%40chromium.org.

[Chris Harrelson]

On Wed, Jul 18, 2018 at 5:05 AM Anita Woodruff <aw...@chromium.org> wrote:

Update:

TAG review is now complete (https://github.com/w3ctag/design-reviews/issues/284) and

we are waiting to hear back from other browser vendors - I have reached out to them on the

spec pull request here.

Hi Anita,

I see that there was some response from Mozilla here. I'd describe the response as not-really-against this feature.

The main comment was about backward compatibility, but Peter's response about falling back to "open a new webpage in order to enter a reply" seemed ok. I suggest adding explicit notes to the chromestatus entry and spec about fallback behavior.

With that, LGTM1 because I don't know what else is actionable here.

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--

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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55579a7b-c43f-4caa-8651-5a875a513dab%40chromium.org.

[PhistucK]

Beside the worrying interoperability aspect, I am worried about the intra-operability aspect of this (Linux, macOS and at least initially Windows earlier than 10 will not be supported). I understand that the native macOS notification system simply does not have the feature (still not great, but a bit more understandable...), but I thought that Linux does not have a standard notification system anyway, so why will it not be supported there?

Also, can the macOS notification system be enhanced to support this in a slightly different way? For example, if it supports buttons at all, have a "reply" button or whatever that opens a Chrome-created overlay/window for entering text?

Regarding interoperability again, will Safari for iOS be able to implement this API with its current notification system? If not, this really might just end up being a Chrome only feature for good which is not, hm... good (:)). :(

☆PhistucK

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

[Yoav Weiss]

On Wed, Aug 8, 2018 at 8:39 AM PhistucK <phis...@gmail.com> wrote:

Beside the worrying interoperability aspect, I am worried about the intra-operability aspect of this (Linux, macOS and at least initially Windows earlier than 10 will not be supported). I understand that the native macOS notification system simply does not have the feature (still not great, but a bit more understandable...), but I thought that Linux does not have a standard notification system anyway, so why will it not be supported there?

Also, can the macOS notification system be enhanced to support this in a slightly different way? For example, if it supports buttons at all, have a "reply" button or whatever that opens a Chrome-created overlay/window for entering text?

Regarding interoperability again, will Safari for iOS be able to implement this API with its current notification system? If not, this really might just end up being a Chrome only feature for good which is not, hm... good (:)). :(

Would Peter's response regarding backward compat also resolve your interop concerns?

IIUC, it will enable developers to know when an inline reply is supported (by browser + platform combination), and handle the cases where it isn't "manually".

Also, if I understand your concerns, they are mostly related to the platform's support of the feature, in which case, e.g. Firefox on Android will be able to implement an equivalent feature, even if non of the other platforms ever implement inline replies in their notification systems.

[PhistucK]

Interoperability (as well as intra-operability), at least as I see it, is also about having a reliable, consistent platform. Non-interoperable and non-intra-operable features slice the consistency and reliability of the platform and makes it not much dependable (the "write once" promise is broken).

Backwards compatibility helps, but implementing it gracefully sometimes comes as a critical bug to the developers when some of their users try feature X on browser Y and it does not work and they have to suddenly fix it.

Yes, you can say that it is their fault for not testing it on other supported browsers or not feature detecting it or not looking at compatibility tables when implementing it, but (for anything other than not testing) - developers do not always know that a feature is even "new" or "mostly not supported across browsers" when they use it. You know, you Google it, you find an example, you copy it, it works with your setup when you test it - there you go, the feature is shipped. Not every developer is careful enough to check those stuff (dare I say, most are not?) and they should probably not be expected to do so.

Are expert developers the primary crowd for the web platform that browsers offer? If so, this is probably a foot-gun, because most are probably not.

(Plus, regarding testing, the matrix is so big that they can be forgiven for not testing everything everywhere, I think. Resources are naturally limited)

But I have gotten too philosophical here, I suppose.

☆PhistucK

[Yoav Weiss]

On Wed, Aug 8, 2018 at 10:27 AM PhistucK <phis...@gmail.com> wrote:

Interoperability (as well as intra-operability), at least as I see it, is also about having a reliable, consistent platform. Non-interoperable and non-intra-operable features slice the consistency and reliability of the platform and makes it not much dependable (the "write once" promise is broken).

Backwards compatibility helps, but implementing it gracefully sometimes comes as a critical bug to the developers when some of their users try feature X on browser Y and it does not work and they have to suddenly fix it.

Yes, you can say that it is their fault for not testing it on other supported browsers or not feature detecting it or not looking at compatibility tables when implementing it, but (for anything other than not testing) - developers do not always know that a feature is even "new" or "mostly not supported across browsers" when they use it. You know, you Google it, you find an example, you copy it, it works with your setup when you test it - there you go, the feature is shipped. Not every developer is careful enough to check those stuff (dare I say, most are not?) and they should probably not be expected to do so.

Are expert developers the primary crowd for the web platform that browsers offer? If so, this is probably a foot-gun, because most are probably not.

(Plus, regarding testing, the matrix is so big that they can be forgiven for not testing everything everywhere, I think. Resources are naturally limited)

But I have gotten too philosophical here, I suppose.

<aside>

Taken to the extreme, this argument could be used to stall any and all progress, as no new feature gets implemented everywhere out the gate.

Reality is that for new features that are not yet universally shipped, developers are expected to take backward compatibility into account (and feature designers need to make sure they can easily do so).

I wouldn't say developers need to be "expert developers" in order to follow these guidelines. When looking up "feature detection", MDN has one of the first relevant results, as part of their "Learn web development" tutorials.

At the same time, we should definitely aim to include feature detection in documentation examples, to make sure the common snippets being copy-pasted around are correct and interoperable.

</aside>

Going back to the matter at hand, I think that for this feature, developers would be able to use a single mechanism to make sure Inline Replies work where the underlying platform supports them, and an alternative mechanism is working elsewhere (due to lack of browser or platform support).

Anita/Peter - Can you confirm that this is indeed the case?

[Peter Beverloo]

Hi all -

Anita's unfortunately moved teams, so I'll be picking this up.

PhistucK, notifications are a bit of a peculiar case in regards to platform consistency - unless we render our own notifications everywhere, the feature will inherently be subject to (major) differences between operating systems, versions and devices. Providing users with an experience that's consistent with the rest of their device takes priority.

Specifically to your macOS/iOS question, inline replies could be supported there, but platform limitations would restrict the maximum number of developer-provided buttons to one if we do. We'd rather make that decision when we know how developers are going to use this :-)

What we can't do is feature detection through property exposure because connecting to the OS' notification center is too slow to delay renderer creation for it. This is a problem we might want to solve with something like Notification.getPlatformCapabilities().

That said, developers will need to handle empty responses, which is effectively analogous to the user being unable to enter a response in the first place. In cases where the difference matters, the `reply` attribute distinguishes the empty string (empty response) from `null` (no response).

Thanks,

Peter

 

☆PhistucK

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/276127bb-c405-4164-89fa-1d6c4be43062%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhmS%2BFMEtFgSWnrq3J6Df-h6PuT_DOUY%2BV60fyy2UBHww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55579a7b-c43f-4caa-8651-5a875a513dab%40chromium.org.

--
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+unsubscribe@chromium.org.

[Yoav Weiss]

On Wed, Aug 8, 2018 at 6:13 PM Peter Beverloo <pe...@chromium.org> wrote:

Hi all -

Anita's unfortunately moved teams, so I'll be picking this up.

PhistucK, notifications are a bit of a peculiar case in regards to platform consistency - unless we render our own notifications everywhere, the feature will inherently be subject to (major) differences between operating systems, versions and devices. Providing users with an experience that's consistent with the rest of their device takes priority.

Specifically to your macOS/iOS question, inline replies could be supported there, but platform limitations would restrict the maximum number of developer-provided buttons to one if we do. We'd rather make that decision when we know how developers are going to use this :-)

What we can't do is feature detection through property exposure because connecting to the OS' notification center is too slow to delay renderer creation for it. This is a problem we might want to solve with something like Notification.getPlatformCapabilities().

That said, developers will need to handle empty responses, which is effectively analogous to the user being unable to enter a response in the first place. In cases where the difference matters, the `reply` attribute distinguishes the empty string (empty response) from `null` (no response).

Just to be clear, you're suggesting that if inline replies are not supported, the the `reply` property on the `notificationclick` event will be null in both non-supporting browsers and non-supporting platforms?

If so, that would indeed enable developers to (retroactively) detect the feature's lack of support, and act on it in a consistent way. 

[PhistucK]

Retroactively is really not great... User guides/tours will have to be vague or verbose in order to convey this...

☆PhistucK

[Peter Beverloo]

Yes.

I think that this change to the platform is sufficiently low-risk that we should go ahead and ship it.

    - The TAG review[1] for the addition has been closed, and has led to several clarifications in the standard.

    - Changes to the API surface are limited and allow for feature detection. Developers have to handle the no-support case anyway to deal with empty responses.

    - Changes to the API surface have been designed with the other platforms in mind[2]. This is also relevant because of Chrome's use of native notification centers.

    - The added capability is powerful, and something users have come to expect from messaging products, particularly on mobile platforms, but increasingly on desktop too.

Coincidentally we started rolling out support for native notifications for Windows 10 users yesterday, adding that group to the reach of this capability too.

Thanks,

Peter

[1] https://github.com/w3ctag/design-reviews/issues/284

[2] https://github.com/anitawoodruff/inline-notification-replies

 

[Yoav Weiss]

That all makes sense. Thanks for clarifying!

LGTM2 to ship.

I sympathize with Phistuck's point regarding retroactive detection not being ideal, but don't think we should block on it. As you suggested, a `Notification.getPlatformCapabilities` API can resolve that in the longer term.

[Philip Jägenstedt]

LGTM3

--

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/CACj%3DBEjrcdLnUMJN17kuHESX2qTOq%2BbOPpCrU7F6i9r3pYXXWg%40mail.gmail.com.