Add support for inline replies by anitawoodruff · Pull Request #132 · whatwg/notifications

anitawoodruff · 2018-05-22T12:40:26Z

This change adds support for notifications that accept text input within their UI, aka 'inline replies'.

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

Requesting TAG review shortly, will link to it below.

- Migrated existing html test to .any.js test + .idl interface to allow testing the new properties from a service worker scope. - See whatwg/notifications#132 for the spec change this tests. - See https://github.com/anitawoodruff/inline-notification-replies for an Explainer.

anitawoodruff · 2018-05-23T13:08:39Z

TAG review now requested at: w3ctag/design-reviews#284

annevk

Thanks for the patch! Here's some initial feedback. Hope that helps.

annevk · 2018-05-23T16:21:17Z

notifications.bs

-<dfn>maximum number of actions</dfn> supported, within the constraints of the
-notification platform.
+<p>A <a>notification</a> has <dfn for=notification lt=action id=actions>actions</dfn>, 
+a <a for=/>list</a> of <a>notification actions</a>, initially empty.


Can we change this to something like "A notification has an action list (a list of actions). It is initially empty." And then use the <dfn> instead of the the <dfn> for "notification action" below since "action" always meant to refer to the individual item and not the associated list.

Have changed the wording but I'm a little confused about where to put the <dfn> tags from your comment, can you clarify?

annevk · 2018-05-23T16:21:30Z

notifications.bs

+a notification, as an alternative to activing the notification itself.
+
+<div dfn-for="notification action">
+  <p>A <a>notification action</a> has a <dfn id=notification-action-type>type</dfn>, that is


Please use one space for indentation.

Also, no need to set an ID for new <dfn>s.

annevk · 2018-05-23T16:24:13Z

notifications.bs

+  <p class=note>Actions of type "<code>button</code>" can only be activated, whereas actions of type
+  "<code>text</code>" allow the user to input text during activation.
+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-title>title</dfn> (a DOMString).


Please don't change the ID. That'll affect folks linking to this.

Thanks for adding a type, but let's make that "a string".

annevk · 2018-05-23T16:24:46Z

notifications.bs

+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-title>title</dfn> (a DOMString).
+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-name>name</dfn> (a DOMString).


Same comments as above and they apply below too.

annevk · 2018-05-23T16:25:20Z

notifications.bs

-also available within the web application.
+also available within the web application. The ability to reply inline to
+notifications during activation is also platform-dependent, so developers are encouraged to
+handle the case where a text action was activated but the reply was null (e.g.


Follow e.g. with a comma.

annevk · 2018-05-23T16:27:22Z

notifications.bs

-  then for each <var>entry</var> in <var>options</var>'s <code>actions</code>,
-  up to the <a>maximum number of actions</a> supported (skip any excess
-  entries), perform the following steps:
+  <li>For each <var>entry</var> in <var>options</var>'s <code>actions</code>:


<li><p> throughout.

annevk · 2018-05-23T16:31:26Z

notifications.bs

+  <li>For each <var>entry</var> in <var>options</var>'s <code>actions</code>:

  <ol>
+    <li>If the user agent does not support additional actions, break.


then break*

annevk · 2018-05-23T16:31:33Z

notifications.bs

+    <code>type</code> property.
+
+    <li>If the user agent does not support additional actions of this
+    <a for="notification action">type</a>, continue.


then continue*

annevk · 2018-05-23T16:33:21Z

notifications.bs

   user, then set <var>action</var> to that <a for=notification>action</a>'s <a for=action>name</a>.

+   <li><p>If one of <var>notification</var>'s <a for=notification>actions</a>
+   with type <i>'text'</i> was activated by the user, and the opportunity to


This should be "<code>text</code>"?

annevk · 2018-05-23T16:33:50Z

notifications.bs

-{{NotificationEvent/action}} attribute initialized to <var>action</var>.
+{{Notification}} object representing <var>notification</var>, the
+{{NotificationEvent/action}} attribute initialized to <var>action</var>, and the
+{{NotificationEvent/reply}} attribute initialized to <var>reply</var>.


Where does the reply variable come from?

Ah good point, guess I can just change the beginning of this sentence to 'given notification, action and reply' which should cover it, yes?

Well, you'll need to update the callers of this algorithm too, then.

Ah yes, that makes sense.

Have updated Step 1.5 of Section 2.7 'Activating a Notification' to 'given notification, action and reply' also. I think this now covers it.

There's two callers of this algorithm, so I don't think that quite covers it. Also, if both are going to set it to null, does it need to be a variable for this algorithm?

Step 1.4 of Section 2.7 ('Activating a notification') sets 'reply' to the text entered by the user during activation, so it shouldn't be null in that case.

I assume you are talking about Section 2.8 ('Closing a notification') as the other caller of this algorithm. That caller does not pass anything for 'action' either right now, so I guess this needs fixing too?

Ah yeah :/ I guess action needs to be the empty string there; @beverloo can confirm.

Yeah, it should be. We could consider changing the event hierarchy a bit to avoid including the action and reply fields with close events - it'd add a bit of boilerplate, but seems cleaner.

NotificationEvent { .notification } NotificationClickEvent : NotificationEvent { .action, .reply }

Hm yeah that would involve adding a whole new interface to the ServiceWorker API, no?

I'm up for doing this but won't this involve quite a lot of work updating idls and tests etc? Could it be done as a followup in a separate change?

Agreed with beverloo@ offline that changing the event hierarchy is out of scope for this change.

Have now updated the 'Closing a notification' algorithm as suggested to pass the empty string & null.

anitawoodruff

Thanks for the notes!

anitawoodruff · 2018-05-24T14:32:49Z

notifications.bs

+a notification, as an alternative to activing the notification itself.
+
+<div dfn-for="notification action">
+  <p>A <a>notification action</a> has a <dfn id=notification-action-type>type</dfn>, that is


anitawoodruff · 2018-05-24T14:35:47Z

notifications.bs

+  <p class=note>Actions of type "<code>button</code>" can only be activated, whereas actions of type
+  "<code>text</code>" allow the user to input text during activation.
+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-title>title</dfn> (a DOMString).


anitawoodruff · 2018-05-24T14:36:03Z

notifications.bs

+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-title>title</dfn> (a DOMString).
+
+  <p>A <a>notification action</a> has a <dfn id=notification-action-name>name</dfn> (a DOMString).


anitawoodruff · 2018-05-24T14:36:59Z

notifications.bs

-also available within the web application.
+also available within the web application. The ability to reply inline to
+notifications during activation is also platform-dependent, so developers are encouraged to
+handle the case where a text action was activated but the reply was null (e.g.


anitawoodruff · 2018-05-24T14:38:17Z

notifications.bs

-  then for each <var>entry</var> in <var>options</var>'s <code>actions</code>,
-  up to the <a>maximum number of actions</a> supported (skip any excess
-  entries), perform the following steps:
+  <li>For each <var>entry</var> in <var>options</var>'s <code>actions</code>:


anitawoodruff · 2018-05-24T14:38:41Z

notifications.bs

+  <li>For each <var>entry</var> in <var>options</var>'s <code>actions</code>:

  <ol>
+    <li>If the user agent does not support additional actions, break.


anitawoodruff · 2018-05-24T14:38:57Z

notifications.bs

+    <code>type</code> property.
+
+    <li>If the user agent does not support additional actions of this
+    <a for="notification action">type</a>, continue.


anitawoodruff · 2018-05-24T14:39:41Z

notifications.bs

   user, then set <var>action</var> to that <a for=notification>action</a>'s <a for=action>name</a>.

+   <li><p>If one of <var>notification</var>'s <a for=notification>actions</a>
+   with type <i>'text'</i> was activated by the user, and the opportunity to


anitawoodruff · 2018-05-24T14:50:19Z

notifications.bs

-{{NotificationEvent/action}} attribute initialized to <var>action</var>.
+{{Notification}} object representing <var>notification</var>, the
+{{NotificationEvent/action}} attribute initialized to <var>action</var>, and the
+{{NotificationEvent/reply}} attribute initialized to <var>reply</var>.


Ah yes, that makes sense.

Have updated Step 1.5 of Section 2.7 'Activating a Notification' to 'given notification, action and reply' also. I think this now covers it.

annevk

Let me know if you're okay with me pushing a formatting fixup commit and when would be a good time to avoid interrupting your work on this PR.

annevk · 2018-05-25T09:57:03Z

notifications.bs

-activating the notification itself. The user agent must determine the
-<dfn>maximum number of actions</dfn> supported, within the constraints of the
-notification platform.
+<p>A <a>notification</a> has an action list (a <a for=/>list</a> of


"action list" needs to be a <dfn> (and some places that currently refer to "actions" need to be updated accordingly)

annevk · 2018-05-25T09:58:13Z

notifications.bs

-<dfn>maximum number of actions</dfn> supported, within the constraints of the
-notification platform.
+<p>A <a>notification</a> has an action list (a <a for=/>list</a> of
+<dfn for=notification lt=action id=actions>actions</dfn>). It is initially empty.


This should become a reference <a for=notification>action</a> and then this <dfn> can replace the <dfn> below so we just have "action" and not "notification action".

anitawoodruff · 2018-05-25T11:02:46Z

Go for it, any time is fine - from my perspective the changes are done aside from your comments :)

annevk · 2018-05-28T12:28:42Z

I addressed some of the formatting issues. There's still at least one outstanding issue though. Review from @beverloo would also be good.

What we need beyond this:

Implementer interest beyond Chrome.
Bugs filed against browsers as per https://github.com/whatwg/meta/blob/master/MAINTAINERS.md#handling-pull-requests

beverloo

This looks good, thanks Anita!

beverloo · 2018-05-31T09:42:30Z

notifications.bs

+ stated otherwise, it is null.
+
+ <p>An <a for=notification>action</a> has a <dfn>placeholder</dfn> (a string). Unless stated
+ otherwise, it is an empty string.


nit: "an empty string" -> "the empty string" for consistency with the rest of the standard. In Section 2.7. too.

beverloo · 2018-05-31T10:07:15Z

notifications.bs


  <ol>
-    <li><p>Let <var>action</var> be a new <a lt="actions">action</a>.
+   <li><p>If the user agent does not support additional actions, then break.


It would be worthwhile to continue to explicitly refer to maximum number of actions - it's not entirely clear to me what "additional actions" would refer to otherwise.

Done. (And sorry for not 'starting a review' for these comments!)

beverloo · 2018-05-31T10:16:18Z

notifications.bs

-    <code>action</code>.
+   <li>
+    <p>If the user agent does not support additional actions of this <a for=action>type</a>, then
+    continue.


This means that we wouldn't append the action to the action list, so they'd be silently dropped. I worry a bit that this would be a footgun, E.g.,

registration.showNotification('title', { actions: [ { type: 'text', action: 'reply', title: 'Reply' }, { action: 'block', title: 'Block' } ] }); addEventListener('notificationclick', event => { event.notification.actions[0] = ???; });

It would be reply for user agents that support text actions, but block for user agents that do not. It's also inconsistent with the note about action buttons, which implies they'd still be presented. ("The ability to...a chat window.")

Instead, I think it would be more predictable if we'd add them to the list of actions anyway, and add a note in Section 2.6. explaining that action buttons of an unsupported type are expected to (gracefully) degrade to button?

ok; removed the stuff here and am adding the following to section 2.6 (Showing a notification), as a note:

"If the platform does not support entering text within a
notification, implementers are expected to treat text actions as regular buttons and update their
type to button accordingly."

How does that sound?

beverloo · 2018-05-31T10:24:13Z

notifications.bs

-{{NotificationEvent/action}} attribute initialized to <var>action</var>.
+{{Notification}} object representing <var>notification</var>, the
+{{NotificationEvent/action}} attribute initialized to <var>action</var>, and the
+{{NotificationEvent/reply}} attribute initialized to <var>reply</var>.


Yeah, it should be. We could consider changing the event hierarchy a bit to avoid including the action and reply fields with close events - it'd add a bit of boilerplate, but seems cleaner.

NotificationEvent { .notification } NotificationClickEvent : NotificationEvent { .action, .reply }

anitawoodruff · 2018-06-04T10:54:35Z

Filed the following implementation bugs against the other browsers:

anitawoodruff · 2018-06-04T10:57:09Z

(Chrome bug is at https://crbug.com/599859 )

lknik

I'd suggest to reword "encuraged" to "required".

anitawoodruff · 2018-07-10T15:19:03Z

@aliams, @hober, @annevk - Please can you comment on whether your respective browsers would be interested in implementing this feature.

Since the native notification centers on Mac, Android, iOS and Windows now all provide this functionality, we think it would make a great addition to the spec.

See the explainer for more details.

Text actions should be treated as button actions for display purposes only - their type should not be updated.

In response to TAG Review, emphasize that user agents should make it clear that replies entered in a notification will be sent to the notification's origin.

annevk · 2018-08-02T06:54:39Z

@anitawoodruff the main input I got at mozilla/standards-positions#91 (comment) from @martinthomson was that it was unclear how to deploy this in a backwards compatible fashion. That is, how can a website use this feature in a way that doesn't make things weird in browsers that don't support it?

beverloo · 2018-08-02T11:22:41Z

Open a window with a view that allows them to send a response, as that's clearly the user's intention by activating that button? The website would want to do something similar if the user doesn't enter an inline reply, i.e. just clicks on the button.

annevk · 2018-08-09T09:22:56Z

It was more about feature detection I think, but it seems that should be doable with "reply" in NotificationEvent.prototype or some such.

annevk · 2018-08-09T09:27:42Z

FWIW, @jakearchibald offered to help with rebasing this. I think the main thing lacking here is explicit interest from one more browser. And perhaps some non-IDL tests.

sorin-davidoi · 2018-09-05T13:40:12Z

Maybe it would be useful to expand the API to allow the reply to be prefilled with some value?

Use-case:

User A sends a message to user B: @b how are you?
User B wants to reply to the message.

It is common in some platforms (such as Mastodon and Twitter) for B's reply to start with @a, and when replying to such a message the input field is prepopulated with @a.

This is not possible to achieve with the current API.

karlhorky · 2019-08-31T14:32:09Z

Just as a note from us all the way over here in user-land, I was just wondering about this particular feature today (whether it was possible with the Notification API):

https://twitter.com/karlhorky/status/1167778767542128643

Use Case: It came up as part of a discussion about whether a Slack PWA could hold its own against an Electron app:

https://twitter.com/karlhorky/status/1167777816466866177

Thanks for listening!

karlhorky · 2019-09-01T11:37:47Z

Ah, I guess this feature is already (partially) implemented in Chrome:

https://twitter.com/beverloo/status/1167824727009832960

However, they are disabled on macOS due to deficiencies in the macOS notification system (extra buttons for "Site Settings" are not allowed):

https://twitter.com/beverloo/status/1167847717361639425

This is a valid user concern, so I have proposed a few ways of dealing with that, including an extra permissions prompt (1) and requiring an installed PWA (2 and 3).

cc @beverloo

xfalcox · 2022-12-02T14:44:07Z

So this been live in Chrome for Windows/ChromeOS/Android for over 6 years, but the update for the spec has been forgot on this PR?

Can we merge this so it will trigger the necessary updates in affects specs like https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#protocol that still doesn't have support for the type attribute in the NotificationAction class ?

Adding Inline Notification Replies to the spec

904bcad

This was referenced May 23, 2018

Add tests for notification inline reply idl properties web-platform-tests/wpt#11122

Closed

Notification Inline Replies w3ctag/design-reviews#284

Closed

annevk reviewed May 23, 2018

View reviewed changes

Updating based on annevk's review

eac4ebe

anitawoodruff commented May 24, 2018

View reviewed changes

annevk reviewed May 25, 2018

View reviewed changes

address some nits

844b530

s/A action/An action

1dba647

beverloo reviewed May 31, 2018

View reviewed changes

anitawoodruff mentioned this pull request May 31, 2018

Support inline replies #68

Open

Addressing (some of) Peter's comments

e308162

annevk mentioned this pull request Jun 4, 2018

Notifications API: inline replies mozilla/standards-positions#91

Closed

Anita Woodruff added 2 commits June 6, 2018 12:18

Update algorithm in 'Closing a notification' to pass action and reply

8467059

Add a note encouraging attribution

56bb9a1

lknik reviewed Jun 26, 2018

View reviewed changes

Change note to mandate attribution

b8426e9

anitawoodruff added 2 commits July 13, 2018 10:39

Amend note on treating text actions as buttons

301ccf8

Text actions should be treated as button actions for display purposes only - their type should not be updated.

Add note on destination of reply data

713eafb

In response to TAG Review, emphasize that user agents should make it clear that replies entered in a notification will be sent to the notification's origin.

jakearchibald mentioned this pull request Aug 2, 2018

Simplifying functional events #135

Merged

Base automatically changed from master to main January 15, 2021 07:46

xfalcox mentioned this pull request Dec 2, 2022

Handle action of type text ErikReider/SwayNotificationCenter#179

Closed


		<p>A <a>notification action</a> has a <dfn id=notification-action-title>title</dfn> (a DOMString).

		<p>A <a>notification action</a> has a <dfn id=notification-action-name>name</dfn> (a DOMString).

Conversation

anitawoodruff commented May 22, 2018 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anitawoodruff commented May 23, 2018

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anitawoodruff May 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anitawoodruff left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anitawoodruff commented May 22, 2018 •

edited by pr-preview bot

Loading

anitawoodruff May 24, 2018 •

edited

Loading