Intent to Ship: NotificationOptions.requireInteraction, and auto-minimize timeout

[John Mellor]

Contact emails

joh...@chromium.org

Spec

https://notifications.spec.whatwg.org/#require-interaction-preference-flag

Summary

Support for the NotificationOptions.requireInteraction property, letting authors hint that a notification should remain readily available until the user clicks or dismisses it.

requireInteraction defaults to false, so unless authors add it, Chrome desktop will start to auto-minimize notifications to the notification center after a few seconds (rather than remaining permanently on-screen as happens today).

Motivation

User studies have shown that users find it annoying when notifications remain on-screen, covering up other apps until dismissed. Additionally, we have observed that existing deployments of notifications frequently dismiss them after a short timeout (indeed, Chrome already does this for all other notifications). This feedback was so universal that we've decided to change our default UI behaviour, and we proposed this spec change so those sites that prefer the old behaviour can opt back into it.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/ZYXDFeTdY6k/discussion

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

The property will be supported but ignored in Chrome for Android, since Android requires that notifications are always minimized there (due to the reduced screen area, and the mature notification center). And Android WebView doesn’t yet support notifications at all.

Demo link

Pass --enable-blink-features=NotificationExperimental to Chrome Canary and visit https://jsbin.com/mipaku

Compatibility Risk

Minor. This hint should help define behaviour that previously was entirely UA-specific.

Firefox: Public support

Edge: No public signals (do not yet ship notifications)

Safari: No public signals

Web developers: Strongly positive

OWP launch tracking bug

https://crbug.com/526158

Entry on the feature dashboard

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

[Chris Harrelson]

LGTM

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

[Philip Jägenstedt]

LGTM2

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[PhistucK]

Does this apply to any new Notification("title")?

Meaning, this is not specifically related to Service Worker notifications, right?

This means that all of the pages that currently use notifications and expect them not to go away, will have to change their code and add that object and that property, right?

This seems a bit risky, however, since the usage is so low anyway (0.004), I guess the risk is pretty low (though notifications are only used when notifying and this may happen multiple times on a single page that remains open for a long time, so the number may be a bit misleading).

Since this has been supported for many years already and behaved the same, I wonder why this has only come up now.

Also, what do you mean by "Android requires that notifications are always minimized there"? What does "minimized" mean in this context? They show up in the notification center (the status line gets filled up with them for a second) and then they remain in the notification center, along with a status line icon. Are you referring to the status line filling up for a second?

☆PhistucK

[Peter Beverloo]

Yes, that is correct.

A number of large websites that have rolled out non-persistent notifications (e.g. Gmail and WhatsApp) already implement auto-dismiss behaviour using a setTimeout(). We know that there are a few use-cases in which you'd like the notification to remain on-screen, which is why we introduced the `requireInteraction` option. We'll be reaching out to large players who we know to depend on this behaviour, and make sure that this is covered in the beta blog post.

Regarding Android, Web Notifications currently never show up as heads-up notifications, like an incoming phone call. This means they're automatically "minimized" to the notification center. This is different from desktop, where they appear as a toast on your screen, and would previously stay there indefinitely.

Thanks,

Peter

[John Mellor]

Update: As of crrev.com/b811b716 (#348871), this is enabled by default in master, so should ship in Chrome 47.

[PhistucK]

https://www.chromestatus.com/feature/5641440986136576 says that the notification are minimized to the notification center after about 8 seconds. However, the desktop notification center was dropped.

Does this mean that non-require-interaction notifications are now closed (along with the "close" event firing) after about 8 seconds?

☆PhistucK

[John Mellor]

Yes. The timeout has been changed to 20 seconds, so non-requireInteraction notifications are closed on Win/Mac/Linux after 20 seconds. On Chrome OS they still just minimize to the notification center after 20 seconds.

In the case of non-persistent notifications on Win/Mac/Linux, we do indeed fire the close event (that was specified in the legacy W3C spec, but removed from the modern WHATWG spec). There isn't currently any equivalent to the close event for persistent notifications.

If Chrome were to integrate with the Win/Mac notification centers, it's likely that the non-persistent notification behavior would remain unchanged (the spec says UAs "should not display non-persistent notification in a platform’s 'notification center'" - though we do this wrong on Chrome OS), but persistent notifications would go back to being minimized rather than closed.

On Android, we only support persistent notifications, and they all go straight to the platform notification center.

[PhistucK]

I updated the entry to say the notifications are closed instead of minimized, except in Chrome OS.

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

The updated text does not look so good, but at least it is up to date.

☆PhistucK