Support for scheduling notifications

[dpogue]

There is currently no way to create a notification to be shown at a later time. One example use case would be a to-do list app that can present reminder notifications as user-specified times.

Both iOS, Android, and Windows 10 support scheduling local notifications.

This could be implemented by a web developer with the Push API, but that would require a server and a network connection. A better solution would be a mechanism for scheduling notifications to be displayed in the future via ServiceWorker APIs, which would allow them to be shown even when offline.

It feels like this is what the timestamp property should be for, but according to the spec as-written, it is not.

[annevk]

I think if you take what you're talking about further you'll get some kind of alarm API that we never really got around to. I'm not entirely sure if such an API should be notification-driven or if it needs to be a lower-level primitive that awakes a service worker on schedule.

[sicking]

Yeah, I think doing this through a generic low-level "wake up a SW on a given time" API is the way to go.

In part because I suspect it'll be as common to want to call openWindow when the timer fires, as to create a notification.

/ Jonas

[mrdewitt]

One thing worth considering in scheduling is that notifications become stale at some point. For example, a calendar app may want a notification to show only just before and during an important event.

One use case where this is important is when a laptop goes to sleep for a while, then the user opens up the laptop later. Today, any notifications created just before sleep will be shown after sleep since AFAIK there are no signals about sleep/wakeup in the browser. However with an expiration time no unnecessary notifications would be shown.

I suppose this could be built into a richer alarms API, but that might still not cover sleep cases very well.

[annevk]

That is the case with existing alarms APIs, you mean?

I wonder if @martinthomson has thought about this kind of API. It seems that with notifications and push, we have all the UI in place this feature could possibly require. Which means that we can introduce it and reuse the notification/push permission, or some such.

[beverloo]

We are definitely interested in developing such an API.

I like to think of it as a Job Scheduler API— a generalization of background sync that can schedule jobs to be executed at a later point in time, given a number of constraints. These could be network related (connectivity type), resource related (charging, screen-on), time based (alarms). By requesting a job to be scheduled we can also define a very flexible permission model, for example based on engagement rather than asking for express permission.

@martinthomson had concerns about such constraints in the early days of background sync, but I think this gives us a great opportunity to design a powerful low-level interface.

I can take a stab at drawing up a proposal during a very long flight this weekend.

/cc @jakearchibald

[dpogue]

There was a proposed API specification for scheduling tasks (https://www.w3.org/TR/task-scheduler/) but it appears to have been dropped. That spec looks like it would have allowed for the use case of showing notifications at future times.

[sicking]

The fact that you'd want to remove the notification seems like a perfect example of why a generic low-level "wake up a SW at this time" API is a good idea. You'd simply schedule two callbacks, one for when you want to create the notification, and a second one for when you want to remove it.

I like to think of it as a Job Scheduler API— a generalization of background sync that can schedule jobs to be executed at a later point in time, given a number of constraints. These could be network related (connectivity type), resource related (charging, screen-on), time based (alarms)

Do we need something more complex than https://www.w3.org/TR/task-scheduler/? It doesn't allow setting up rules like "Fire a callback at 5pm, but only if the user is online", but are there really common use cases for that?

I'm not saying it'll never be needed. But it seems like a simple scheduler API will get us very far for now.

[jakearchibald]

@sicking

I suspect it'll be as common to want to call openWindow when the timer fires, as to create a notification.

At the moment we only allow openWindow in response to a user interaction. I can't think of reasons we'd want to change that, especially as the interaction with the lockscreen would be really complicated.

[annevk]

@jakearchibald well, we need to enable Skype-like use cases at some point. Though maybe that could be some special "calling" notifications. But that wouldn't really give them the UX they seem to want.

[jakearchibald]

@annevk Notifications can already have buttons (accept, decline) & a sound - that's not a bad MVP. Although yeah, it's not exactly how alarms & calls work today.

Being able to open pages on top of the lock-screen would need to be something super-privilaged.

[martinthomson]

So the basic mechanism that will work here is to generate a notification in response to a timed push. However that's not going to work offline. That leaves us with setTimeout(_ => showNotification(), bigNumber), which has a pretty nasty impact on SW lifecycle. I would not want to see this as a widget on notifications though, but a service worker primitive.

I have no concern here about the feature, I think that the calendaring/alarm use case is pretty straightforward. However, like with push and background sync, we need to ensure that sites remain accountable for their unobservable actions. On my Android device, I get a little system tray icon when an alarm is set, which might be overkill here, but maybe not.

Whole-screen notifications is a separate problem to consider. I don't think that we want "open page over the lock screen", but more "make this notification full screen", which might progress to "here's some HTML to show in the notification". And I agree with @jakearchibald that this is going to require augmented powers.

[beverloo]

Do we need something more complex than https://www.w3.org/TR/task-scheduler/?

That API very specifically focuses on the time constraint. Similarly, background sync can be considered a first step towards the connectivity constraints. Do we need more separate APIs for screen status, charging, activity and potentially basic location-based constraints?

I think there's an opportunity where we can avoid introducing many very similar APIs. The descriptor idea used in the Permission API would be appropriate as well.

It doesn't allow setting up rules like "Fire a callback at 5pm, but only if the user is online", but are there really common use cases for that?

Each of these constraints will need lots of thoughts in regards to use-cases and practical need, of course. Combinational constraints can be powerful: remind me to take an umbrella if it's raining at 8am, but I would expect them to be more rare than needing access to the indiviual constraints.

@jakearchibald well, we need to enable Skype-like use cases at some point. Though maybe that could be some special "calling" notifications. But that wouldn't really give them the UX they seem to want.

This would be exactly what the user expects on Android. I agree with Martin that this is a separate topic.

However, like with push and background sync, we need to ensure that sites remain accountable for their unobservable actions. On my Android device, I get a little system tray icon when an alarm is set, which might be overkill here, but maybe not.

Absolutely. We require express user permission for push and notifications, but are moving to the realms of granting sites a budget for background operations based on the user's engagement with it. Any solution would have to allow for other security models as well.

In addition, when scheduling a task/notification, it's important to know up-front whether it's going to happen or not. A calendar app could offer a notification if the user can't be notified for an event at the appopriate time. (For whatever reason.)

[davidhewitt]

Did any such scheduler API get proposed in the end? I have not managed to find anything on the subject.

[pahlers]

Any updates about this request?

[annevk]

There's no concrete proposal for this.

[pahlers]

@annevk Can we make one?

[annevk]

Yeah, you could certainly try to work something out. Beyond that there needs to be implementer interest. I'd guess there might be some, but given how this hasn't been a priority for two years, I suspect it'll take a while for anything to get traction here. So it might be a long process. I recommend reading https://whatwg.org/faq#adding-new-features (and maybe some other entries too) and https://whatwg.org/working-mode to get a feeling things.

[joshbuker]

+1 on this feature request

This is what I've found so far related to scheduled notifications:

• https://web.dev/notification-triggers/
• https://github.com/beverloo/notification-triggers/issues/7