Add customizable ttl to requireInteraction notifications

[Yavanosta]

Disposition: Currently notifications has only two options. Set requireInteraction: false and show notification only for approximately 20 seconds or set requireInteraction: true and show notification that will shown forever until user close it.

Problem: Sometimes requireInteraction: true can be send to irrelevant device or at irrelevant time and cause problems. For example we send notification when user already locked computer and went home from office, so in the morning this notification will be already useless. Another example is sending notifications to some sort of street smart screens or computers working in kiosk mode. Such computers does not have keyboard or mouse and require some IT specialist to close them.

That's why sending requireInteraction: true notifications is very risky thing.

Hypothesis: If user has not reacted to requireInteraction: true notifications for a long time, then something goes wrong and we have to solve it somehow.

Proposal: add new field ttl in milliseconds to requireInteraction: true notifications that give ability to automatically close such notifications in reasonable time for example 1 or 2 hours.

[beverloo]

Without requireInteraction, the on-screen display time of a notification will depend on the operating system. The goal here is to make sure users have a consistent, system-wide experience. The requireInteraction flag indicates that the user is expected to respond to the notification, and should thus continue to be readily available.

I don't think that we (Chrome) would be willing to offer configurable TTLs of less than 10 minutes or so, to avoid developers trying to override OS configuration, and that already feels fairly arbitrary.

Maybe this is a dismissal problem that would be better addressed through the Push API? Maybe this is something where notification triggers could be considered? @rknoll

[rknoll]

Notification triggers have this use case in mind as a future extension. Instead of defining a ttl in milliseconds, developers could provide a closeTrigger. That could trigger (and close the notification automatically) based on a timestamp, local time, or other trigger types.

An example could look like this:

// Shows a notification in T+5 minutes, and closes it in T+10 minutes.
sw.showNotification(title, {
  body,
  showTrigger: new TimestampTrigger(Date.now() + 5 * 60 * 1000),
  closeTrigger: new TimestampTrigger(Date.now() + 10 * 60 * 1000),
});

Thoughts?

[Yavanosta]

Thank you for reply!

I understand risks of giving ability to override system behavior. The main idea of my proposal is add some kind of fallback for notifications that may be have some issue with them. I believe that in many cases requireInteraction time is in fact limited for some maybe big, but not infinity period of time.

Imagine that you return from vacation, unlock your computer which was turned on for two weeks and see some notifications from the previous week. In many cases this notification will be already outdated.

So goal is to show notification that for sure attracts user attention (you can't ignore notification that is shown on the screen for hours), but somehow close them when their life time becomes incredibly large. Like a watch dog that will kill notifications that are "probably hanging".

Idea with closeTrigger looks really great! Much better then my!

[Yavanosta]

Found one more example illustrating the problem.

Let's imagine you have an group call with your colleagues that will lasts for 1 hour. I think it's reasonable to send requireInteraction: true notification in this case, because you accepted this meeting and colleagues are waiting for you. And even in 30 minutes this notification make sense, because you still can join meeting. So the usage of requireInteraction: true is justified.

But when meeting is already over and you anyway missed it I think it will be better to hide this notification, because it's become useless.

Hope the idea is clear now :)

[mnoorenberghe]

Could you explain why the straightforward solution of calling close() on the existing notification programmatically isn't sufficient?

I guess one case is if the Service Worker runtime gets shutdown between when the notification shows and when you would like to dismiss the notification… though that wasn't mention so far…

[Yavanosta]

I guess one case is if the Service Worker runtime gets shutdown between when the notification shows and when you would like to dismiss the notification… though that wasn't mention so far…

Yes you are right. For example in Chromium your event handler can't stay alive more than five minutes even if you call waitUntil on ExtendableEvent

https://cs.chromium.org/chromium/src/content/renderer/service_worker/service_worker_timeout_timer.h?q=service_worker_timeout_timer.h&sq=package:chromium&g=0&l=111-114