Intent to Implement: Notification.get() and Notification.data

[Peter Beverloo]

Contact emails

pe...@chromium.org

Spec

https://notifications.spec.whatwg.org/#service-worker-api

https://notifications.spec.whatwg.org/#api ("data" attribute)

Summary

Support for the static Notification.get() method for getting all existing persistent notifications created by the current origin.

Support for the Notification.data attribute, which allows authors to attach some (immutable) data to a persistent Web Notification they are displaying.

Motivation

With Push Messaging and the Service Worker-based Notification API now being supported, we're looking at ways to make developer's lives easier.

By supporting Notification.get(), we enable developers to prune notifications which are no longer relevant and provide much better UX by enabling them to coalescing multiple notifications.

By supporting Notification.data, we enable developers to have a much cleaner way of deciding *which* notification was clicked on when the "notificationclick" fires. For example, it could contain the ID of an e-mail thread, the URL to open a window for, or slightly more advanced objects for complex webapps.

Compatibility Risk

Both have been in the Web Notification specification for quite some time, but we are the first browser to implement and ship this feature.

Ongoing technical constraints

On Android, the platform does not tell us which notifications are being shown on behalf of Chrome. In order to support these features, but also in order to support other parts of Chrome which need to know such information, we need to store this information in a database.

This database will not live in Blink - instead, it will live in //content/. It's needed for other reasons as well, but comes in convenient for implementation of these features.

A design document is available.

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

Yes, except the Android WebView, because we don't support Web Notifications there yet.

OWP launch tracking bug?

None.

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

[Peter Beverloo]

For competency, note that I filed two spec issues to flesh out the semantics of these APIs, but since this is just an Intent to Implement that should be OK.

https://github.com/whatwg/notifications/issues/37

https://github.com/whatwg/notifications/issues/38

Furthermore, the two Chromium implementation bugs are as follows:

Notification.get() - https://crbug.com/442143

Notification.data - https://crbug.com/442129

Thanks,

Peter

[Elliott Sprehn]

Should it be getAll() to match other APIs?

[Alex Russell]

On 5 Mar 2015 5:49 pm, "Elliott Sprehn" <esp...@chromium.org> wrote:
>
> Should it be getAll() to match other APIs?

Yeah, I think it should be. "get()" is confusing because of JS getter syntax.

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

[Peter Beverloo]

Per the following commit this has been updated to be ServiceWorkerRegistration.getNotifications():

  https://github.com/whatwg/notifications/commit/11f25cccb909adc7e8b5569f8e5e20c482234860

This also enables author to get the notification associated with their Service Worker from within a document.

Thanks,

Peter

[Mounir Lamouri]

I have some concerns about Notification.data. It seems to me that we are
introducing yet another storage mechanism in the platform. It is true
that developers want to be able to identify a notification after the
user has interacted with it but can we solve that problem with a simpler
solution?

What about having Notification.id instead? We could have this ID
provided by the platform and opaque to the web page with only the
guarantee that it is unique. With that mechanism, instead of saving the
contextual data inside the Notification object, the developers could
save it in their application database and have the Notification.id to
associate the data with.

I am also slightly worried with Notification.data being a data storage
mechanism that technically lives in a different scope than the web page.
It would be very easy for implementers to shoot themselves in the foot
and have nasty bugs.

-- Mounir

[Peter Beverloo]

Thank you for your feedback, Mounir!

Notification.data is only meant for storing small amounts of data: the URL to open when the notification was clicked on, the id of an e-mail thread, and perhaps a structure for the more advanced web apps.

Because the lifetime of the notification is largely out of the developer's hands - it's user visible UI which can be dismissed at any time (with no close event!), it's neither convenient nor appropriate for storing anything other than such information. It's unreliable.

One important thing to consider is that the learning curve for using persistent notifications (and Push) already is very high. This is workable for the large Web apps of the world, but it poses a significant entry barrier for the vast long-tail of developers. For them, there is unlikely to be an application database at all. They just want to show a notification which opens a URL.

Adding yet another requirement, IndexedDB, on top of an existing, long list of requirements for a very common use-case does not sound reasonable to me. We want to optimize for the common case, not complicate it further.

I encourage you to file an issue against the Notification API specification if you feel this is worth pursuing further.

    https://github.com/whatwg/notifications/issues

Implementation wise, I agree that we should impose some reasonable limit to prevent abuse, which we'll definitely think about.

Thanks,

Peter

[Mounir Lamouri]

On Sat, 7 Mar 2015, at 19:34, Peter Beverloo wrote:
> Thank you for your feedback, Mounir!
>
> Notification.data is only meant for storing small amounts of data: the
> URL
> to open when the notification was clicked on, the id of an e-mail thread,
> and perhaps a structure for the more advanced web apps.

If it's meant for small amount of data, I think the specification should
define a strict limit to prevent browser specific behaviour that will
break interop.

> Because the lifetime of the notification is largely out of the
> developer's
> hands - it's user visible UI which can be dismissed at any time (with no
> close event!), it's neither convenient nor appropriate for storing
> anything
> other than such information. It's unreliable.

Arguably, your proposal gives the solution to that: getNotifications()
should solve this problem by allowing developers to keep track of which
Notifications they have running at any time. Though, I agree that this
is not ideal and a real problem.

> One important thing to consider is that the learning curve for using
> persistent notifications (and Push) already is very high. This is
> workable
> for the large Web apps of the world, but it poses a significant entry
> barrier for the vast long-tail of developers. For them, there is unlikely
> to be an application database at all. They just want to show a
> notification
> which opens a URL.
>
> Adding yet another requirement, IndexedDB, on top of an existing, long
> list
> of requirements for a very common use-case does not sound reasonable to
> me.
> We want to optimize for the common case, not complicate it further.

Using a storage mechanism can be reduced to something like:
```js
storage.get(my_id).then(function(data) {});
storage.set(my_id, data);
```

I do not think it is fair to say that a developer willing to use Push
Notifications with a Service Worker can't take the burden of using raw
IDB or a library on top of it.

> I encourage you to file an issue against the Notification API
> specification
> if you feel this is worth pursuing further.
> https://github.com/whatwg/notifications/issues
>
> Implementation wise, I agree that we should impose some reasonable limit
> to
> prevent abuse, which we'll definitely think about.

https://github.com/whatwg/notifications/issues/39

Note that if we go with Notification.data the limit should be set by the
specification and not be implementation specific.

-- Mounir

[Paul Kinlan]

On Mon, Mar 9, 2015 at 11:24 AM Mounir Lamouri <mou...@lamouri.fr> wrote:

On Sat, 7 Mar 2015, at 19:34, Peter Beverloo wrote:
> Thank you for your feedback, Mounir!
>
> Notification.data is only meant for storing small amounts of data: the
> URL
> to open when the notification was clicked on, the id of an e-mail thread,
> and perhaps a structure for the more advanced web apps.

If it's meant for small amount of data, I think the specification should
define a strict limit to prevent browser specific behaviour that will
break interop.

Urgh, have you ever tried to make sure the size of an object fits?  I am also not looking forward to the developer relations aspect of this: mainly managing developers who complain the limit is arbitrary and too small.

 

> Because the lifetime of the notification is largely out of the
> developer's
> hands - it's user visible UI which can be dismissed at any time (with no
> close event!), it's neither convenient nor appropriate for storing
> anything
> other than such information. It's unreliable.

Arguably, your proposal gives the solution to that: getNotifications()
should solve this problem by allowing developers to keep track of which
Notifications they have running at any time. Though, I agree that this
is not ideal and a real problem.

As a developer, when do I run get Notifications to do the clean-up to remove entries from the DB?  I like the idea of the lifetime of the data being tied to the notification.

 

> One important thing to consider is that the learning curve for using
> persistent notifications (and Push) already is very high. This is
> workable
> for the large Web apps of the world, but it poses a significant entry
> barrier for the vast long-tail of developers. For them, there is unlikely
> to be an application database at all. They just want to show a
> notification
> which opens a URL.

Playing devils advocate here: this is a very specific use case, and a good one.  Why can't the data object just be a URL?  For anyone with a more complex scenario, they could use this URL as an entry point into either the Cache API, IndexedDB or another data store (heck, even a data uri).

 

>
> Adding yet another requirement, IndexedDB, on top of an existing, long
> list
> of requirements for a very common use-case does not sound reasonable to
> me.
> We want to optimize for the common case, not complicate it further.

Using a storage mechanism can be reduced to something like:
```js
storage.get(my_id).then(function(data) {});
storage.set(my_id, data);
```

I do not think it is fair to say that a developer willing to use Push
Notifications with a Service Worker can't take the burden of using raw
IDB or a library on top of it.

I think it is an entirely fair thing to say, after all we have the Cache API to get around this same problem.  The second that we mandate IDB to transfer data we instantly increase the barrier to entry.

 

> I encourage you to file an issue against the Notification API
> specification
> if you feel this is worth pursuing further.
>     https://github.com/whatwg/notifications/issues
>
> Implementation wise, I agree that we should impose some reasonable limit
> to
> prevent abuse, which we'll definitely think about.

https://github.com/whatwg/notifications/issues/39

Note that if we go with Notification.data the limit should be set by the
specification and not be implementation specific.

-- Mounir

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

[Anne van Kesteren]

On Mon, Mar 9, 2015 at 12:41 PM, 'Paul Kinlan' via blink-dev
<blin...@chromium.org> wrote:
> Playing devils advocate here: this is a very specific use case, and a good
> one. Why can't the data object just be a URL? For anyone with a more
> complex scenario, they could use this URL as an entry point into either the
> Cache API, IndexedDB or another data store (heck, even a data uri).

This isn't really the right venue to be having this discussion, but we
did consider a string (which would be the data type for a URL) and
then it was argued that it should be more flexible. There's already
other places than IDB that can store structured clones (see history
API) so I don't really think it's prohibitive. It's infrastructure you
need to have in place regardless.


--
https://annevankesteren.nl/

[Alex Russell]

On Sat, Mar 7, 2015 at 11:34 AM, Peter Beverloo <pe...@chromium.org> wrote:

Thank you for your feedback, Mounir!

Notification.data is only meant for storing small amounts of data: the URL to open when the notification was clicked on, the id of an e-mail thread, and perhaps a structure for the more advanced web apps.

I agree this is not onerous.

 

Because the lifetime of the notification is largely out of the developer's hands - it's user visible UI which can be dismissed at any time (with no close event!), it's neither convenient nor appropriate for storing anything other than such information. It's unreliable.

This seems like an important point and one we can make clearer, e.g., by outlining the expected behavior across UA restarts. E.g., if Chrome is closed, what happens to the notification? To the .data property?

[Peter Beverloo]

On Mon, Mar 9, 2015 at 10:22 PM, Alex Russell <sligh...@google.com> wrote:

On Sat, Mar 7, 2015 at 11:34 AM, Peter Beverloo <pe...@chromium.org> wrote:

Thank you for your feedback, Mounir!

Notification.data is only meant for storing small amounts of data: the URL to open when the notification was clicked on, the id of an e-mail thread, and perhaps a structure for the more advanced web apps.

I agree this is not onerous.

 

Because the lifetime of the notification is largely out of the developer's hands - it's user visible UI which can be dismissed at any time (with no close event!), it's neither convenient nor appropriate for storing anything other than such information. It's unreliable.

This seems like an important point and one we can make clearer, e.g., by outlining the expected behavior across UA restarts. E.g., if Chrome is closed, what happens to the notification? To the .data property?

The specification specifies the lifetime of notifications in the following section:

    https://notifications.spec.whatwg.org/#lifetime-and-ui-integration

The summary is that the lifetime of persistent notifications should be tied to the platform's notification center, when available. The .data property will match whatever this is.

In practice, this means that on Android notifications can outlive UA restarts. On other platforms, Chrome's message center handles display of notifications. Therefore notifications can outlive browser restarts on Chrome OS, but are tied to the lifetime of the browser on other platforms, as the message center is part of Chrome.

This also describes whether we notifications are being displayed to the user.

SWR.getNotifications() will of course reflect this all.

Thanks,

Peter

[Philip Jägenstedt]

Hi Peter,

ServiceWorkerRegistration.getNotifications() and Notification.data
both sound like good additions!

It seems to me that the storage problem of Notification.data would be
the same if it were a string, with the difference that it would be
easier to specify a size limit to a string. Giving each Notification
an implementation-provided unique ID that an app can use to associate
data in some other storage would of course work, but that seems very
annoying for the 99% of cases where the app only wants to store a
short string.

It looks like you can also store an arbitrary amount of data in e.g.
Notification.sound, which is even reasonable if it's a data URI of a
sound.

Peter, are you intending to have any size limits in the implementation
that *could* be standardized? If the issue could be avoided entirely
that would be nice...

Philip

[b.ke...@samsung.com]

On Wednesday, March 11, 2015 at 12:14:48 AM UTC-4, Philip Jägenstedt wrote:

Hi Peter,

ServiceWorkerRegistration.getNotifications() and Notification.data
both sound like good additions!

It seems to me that the storage problem of Notification.data would be
the same if it were a string, with the difference that it would be
easier to specify a size limit to a string. Giving each Notification
an implementation-provided unique ID that an app can use to associate
data in some other storage would of course work, but that seems very
annoying for the 99% of cases where the app only wants to store a
short string.

It looks like you can also store an arbitrary amount of data in e.g.
Notification.sound, which is even reasonable if it's a data URI of a
sound.

Peter, are you intending to have any size limits in the implementation
that *could* be standardized? If the issue could be avoided entirely
that would be nice...

Philip

A related question: is there any advantage doing the serialization in the platform over just making data a string with a relatively high size limit thus allowing developers to json format an arbitrary (but not "too" big) object graph? Of course the spec has to change for this as now it says the type of data is 'any'. I suppose it would much straightforward to define the limit in terms of a string length.

Balazs

[Peter Beverloo]

On Wed, Mar 11, 2015 at 4:14 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Hi Peter,

ServiceWorkerRegistration.getNotifications() and Notification.data
both sound like good additions!

It seems to me that the storage problem of Notification.data would be
the same if it were a string, with the difference that it would be
easier to specify a size limit to a string. Giving each Notification
an implementation-provided unique ID that an app can use to associate
data in some other storage would of course work, but that seems very
annoying for the 99% of cases where the app only wants to store a
short string.

It looks like you can also store an arbitrary amount of data in e.g.
Notification.sound, which is even reasonable if it's a data URI of a
sound.

We've already seen developers store bits of data in the hash part of the icon URL :-(.

 

Peter, are you intending to have any size limits in the implementation
that *could* be standardized? If the issue could be avoided entirely
that would be nice...

Yes, I do intend to have a limit, but I have not yet decided what a reasonable limit would be. The purpose of this limit would be to avoid abuse, for which UMA counters will be added.

I suggested adding a limit to the specification, but it's not great to just define an arbitrary limit for no reason. I think it's more valuable for now for the specification to suggest appropriate uses, and decide on specifying a limit when UMA data can back up this decision.

https://github.com/whatwg/notifications/issues/38

On Wed, Mar 11, 2015 at 6:23 AM, <b.ke...@samsung.com> wrote:

A related question: is there any advantage doing the serialization in the platform over just making data a string with a relatively high size limit thus allowing developers to json format an arbitrary (but not "too" big) object graph? Of course the spec has to change for this as now it says the type of data is 'any'. I suppose it would much straightforward to define the limit in terms of a string length.

Balazs

It's much less convenient, and we already have the infrastructure place. Randomly truncating a JSON-encoded string provided by the developer is not nice - I'd rather reject altogether.

Thanks,

Peter

[b.ke...@samsung.com]

I meant that we would reject the notification with a proper error if data exceeds the limit.

I don't really see how is it much less convenient. Isn't it just a matter of passing JSON.stringify(myFancyData) instead of just myFancyData?

[Philip Jägenstedt]

On Fri, Mar 13, 2015 at 3:39 AM, Peter Beverloo <pe...@chromium.org> wrote:

On Wed, Mar 11, 2015 at 4:14 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Hi Peter,

ServiceWorkerRegistration.getNotifications() and Notification.data
both sound like good additions!

It seems to me that the storage problem of Notification.data would be
the same if it were a string, with the difference that it would be
easier to specify a size limit to a string. Giving each Notification
an implementation-provided unique ID that an app can use to associate
data in some other storage would of course work, but that seems very
annoying for the 99% of cases where the app only wants to store a
short string.

It looks like you can also store an arbitrary amount of data in e.g.
Notification.sound, which is even reasonable if it's a data URI of a
sound.

We've already seen developers store bits of data in the hash part of the icon URL :-(.

 

Peter, are you intending to have any size limits in the implementation
that *could* be standardized? If the issue could be avoided entirely
that would be nice...

Yes, I do intend to have a limit, but I have not yet decided what a reasonable limit would be. The purpose of this limit would be to avoid abuse, for which UMA counters will be added.

I suggested adding a limit to the specification, but it's not great to just define an arbitrary limit for no reason. I think it's more valuable for now for the specification to suggest appropriate uses, and decide on specifying a limit when UMA data can back up this decision.

https://github.com/whatwg/notifications/issues/38

I see, it makes sense to revisit the issue after data from UMA counters is available.

Philip