Intent to Implement: Notification Triggers

[Richard Knoll]

Contact emails

kno...@chromium.org, pe...@chromium.org

Explainer

https://github.com/beverloo/notification-triggers

Design doc

Notification Triggers Design Doc

Notifications API Standard: https://notifications.spec.whatwg.org/

We're still going through some rounds of internal review, a TAG review will be requested immediately after.

Summary

Allow Web Notifications to be shown at a later time in the future.

Motivation

With background sync/fetch APIs, Web Applications are increasingly getting offline capabilities. This is even more important when installed as a PWA. To show Notifications, apps can either show them immediately (requires users to have Chrome running), or as a response to a Push Message (requires network connectivity). There is no reliable way of showing a Notification for a scheduled meeting as a Web Application right now because receiving a Push Message is an unreliable and expensive operation on mobile devices. Having a declarative way of specifying when a Notification should be shown reduces the effort for developers and allows browsers to optimize this use case.

Risks

Interoperability and Compatibility

This feature takes another step at making Web Applications offline ready. This will allow use cases like calendars to be implemented as a PWA instead of a native Android app.

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: Asked for by multiple partners

Ergonomics

This feature will be used in offline capable applications. They will use other APIs targeted towards good offline experiences like Background Sync/Fetch.

Depending on how developers chose to work around this missing feature, we expect using this new API to be more resource efficient and improve reliability for users. It could also reduce the number of Push Messages required as applications can specify when the Notifications should be shown instead of having to send a Push Message at the right time.

Activation

This feature is an extension to the existing Notifications API. Developers can easily use this new capability by providing the new options to their existing calls to the Notifications API. Polyfills are not possible for this feature as it requires to schedule tasks on the underlying OS, although sending a push notification continues to be an option.

Debuggability

Notifications that are scheduled to be shown in the future via this API can be retrieved and removed using the existing Notifications API. This API will be extended to allow developers to list all scheduled notifications with their corresponding trigger. Notifications are not exposed to DevTools thus we do not plan to make any changes to it.

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

Yes. We will start with Android, but we intend to implement it for all platforms. Android WebView is excluded because notification support is not available there.

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

[Michaela Merz]

Question: Will that also fix the problem of not being able to display notifications while a mobile device is dozing? Notifications - delayed or not, make no sense if the can't wakeup the PWA while the phone is sleeping.

m.

[kno...@chromium.org]

Thanks for the response!

Unfortunately we have the same limitations as any native app on the respective platforms, but with this we bring another functionality of native apps to the web.

As for doze mode in Android, AlarmManager#setExactAndAllowWhileIdle is probably our best option, which wakes up the mobile device as long as the events are not too close to each other while dozing.

Note that the PWA will only be notified when the user interacts with the notification as we do not run JavaScript when the specified time is reached. This would be more like a General Alarms API and not part of this one.

- Richard

[Michaela Merz]

Richard: Just so that I understand: I'll set a notification trigger say - for 6 hours from now - but I won't get any notification when a mobile device is in doze? I really appreciate the principle idea of delayed notifications - it's truly a great idea, but you know what is worse than not having some cool functionality? It's having cool functions that may or may not work.

Here's the thing: While Skype and other native apps seem to have no problem with notifications, notifications aimed at PWAs won't be displayed when the Andoid devices is dozing. This may be a bug (report is filed) or a feature, but it devalues any urgent notification to the point of utter uselessness. And frankly - I don't understand that. Any self-developed app can implement FCM notifications that will be able to cut through doze without problem. But Chrome can't? Really?

Note that the PWA will only be notified when the user interacts with the notification as we do not run JavaScript when the specified time is reached. This would be more like a General Alarms API and not part of this one.

- Richard

Of course. We're talking notifications. Not Javascript wakeup-calls ;)

Michaela

[kno...@chromium.org]

Notification triggers make all of that more reliable :-)

You would get the notification even when the mobile is in doze, in the worst case it might be 9 minutes late if they get scheduled close to each other (see https://developer.android.com/training/monitoring-device-state/doze-standby#assessing_your_app).

Also, consider the case where your device is offline at that point, push messages won't arrive until it's back online..

So if an app knows in advance when to show a notification, for example a calendar, it would schedule it and Chrome would make sure that it is shown at the requested time.

[rhal...@google.com]

Please make sure this gets a privacy review.

[roll...@gmail.com]

Richard - Just to add to my previous post - I just coded a quick native app able to receive FCM notifications. Guess what: No time delays. no 9 minute wait penalties, every FCP push is received by a cell phone in doze within seconds.

Now - why isn't that possible for web-push?

M.

[roll...@gmail.com]

Thanks Richard - but I don't understand. Maybe it's just me, but  setAndAllowWhileIdle .. has been available since Android 6.0 - yet .. I can't web-push any notification that would wake a device from doze. And what's with the arbitrary 9 minute time penalty? Who comes up with stuff like that? Why not 5 minutes, or 10 minutes? And - Is this penalty reset when the device is woken up? So - let's say it would cut through doze: FCM push "Incoming message" .. I pickup my phone, look who send what (which will un-doze the device) and put the device on the table again. Now -. what happens with a new incoming message 2 minutes later? Is this notification being blocked because there was another notification 3 minutes ago or is it allowed because I un-dozed the device in between? Are native apps subjected to the same, emm, weird restrictions or is it because we're "just" doing web-apps? 

But that's all more or less mute for the time being, as I can't push any notification to a dozing device anyway.

Michaela

On Monday, February 11, 2019 at 11:07:26 AM UTC-6, Richard Knoll wrote:

[kno...@chromium.org]

I feel like we're mixing two different things here:

1) Showing a notification immediately as a response to a push message

2) Scheduling a notification on the device to be displayed later

For (1) I can see http://crbug.com/777106 that handles the issues you see when the device is in doze mode.

While this is related to Notification Triggers it affects more than just Notifications as the ServiceWorker does not seem to be called in doze.

As for this intent to implement I'd like to focus on (2) as there is no Push Message required for this new API. It is much more focussed on use cases like a calendar which knows quite long in advance when to show a notification, as opposed to a real time chat where this needs to be sent via Push API.

Thanks!