Feature request: optional timeout for heads-up notifications

Desktop
1

Hi everyone,

I’d like to propose adding an optional timeout for heads-up notifications.

Current behavior

Notifications remain visible until manually dismissed or hovered, after which they collapse into the calendar indicator.

Context

This behavior is intentional (as discussed here):
Gnome Notifications Timeout (#112) · Issues · GNOME / gnome-shell · GitLab i.e. so users don’t miss notifications when away from their device.

Problem

In practice, this creates some friction:

  • Notifications often remain on screen even after being seen, requiring manual dismissal
  • This interrupts workflow, as it requires pointer movement unrelated to the user’s current task
  • Persistent notifications can expose private content in shared/public environments
  • It becomes inconvenient when the user is passively viewing content (e.g., watching a video)

Proposal

Introduce an optional timeout for heads-up notifications:

  • Notifications automatically collapse after a configurable duration
  • Could be limited to low/normal urgency notifications
  • This could also be exposed in Settings → Notifications as a toggle “Auto-dismiss notifications”

This would align with the freedesktop notification spec, which allows expiration timeouts depending on urgency:

Why this helps

  • Reduces interaction cost
  • Improves privacy in shared environments
  • Maintains flexibility without changing default GNOME behaviour

Happy to hear thoughts!

1 Like
2

Since 49 i think all notifications required manually hovering over them to dismiss them. Not sure if that one is intentional too

3

If notifications require manual dismissal, they probably have high urgency.

4

Yes I feel so too.

Notifications in Android have importance levels too (https://developer.android.com/develop/ui/views/notifications#importance) i.e. :

  • Urgent: makes a sound and appears as a heads-up notification.

  • High: makes a sound.

  • Medium: makes no sound.

  • Low: makes no sound and doesn’t appear in the status bar.

But all notifications collapse into the notification drawer after the timeout regardless

5

But currently all notifications require manual dismissal, regardless of their urgency.

6

Not the case here for non-urgent notifications. They are shown for a while and then disappear without needing to hover them. Only if there is absolutely no activity on the computer they stay until the users interacts with the computer (not necessarily the notifications) to ensure you don’t miss notifications that appeared while you were away from the computer.

7

Thanks for clarifying!
Could you please share a few examples of such non-urgent notifications? For me, all notifications stay persistent on the top until I dismiss them.

How is “activity” defined? Is it the movement of the pointer?

8

That would mean all notifications by Fractal and Software have urgent priority. Is there any way I can troubleshoot this aside from looking directly at the code?

9

You could generate simple notification with the default urgency using notify-send test.

I think any form of input, but I haven’t looked at the code. In my tests the timeout starts after either keyboard or mouse input. To test this you can use something like sleep 1; notify-send test, otherwise the enter key release happens after the notification has been sent, counting as input.

10

Check with dbus-monitor what the urgency of the notifications is.

1 Like
11

Mmmm it works now, but I swear in the past I had to manually move them away :melting_face:

12

Thanks for clarifying! This is immensely helpful. I can see now that the timeout starts after keyboard or mouse input.

While testing this, I noticed a few things that I’m still trying to understand:

  1. In some cases, notifications that collapse into the calendar don’t always show the small white indicator next to the time. Is that expected behaviour?

  2. Since the indicator already exists to surface missed notifications, I’m curious about the need for the additional “activity” check before starting the timeout.

  3. In scenarios where the user is passively engaged (e.g. watching a video or reading), the notification can remain visible for a long time without input. This still seems to have some privacy implications.

  4. If multiple notifications arrive while the user is away, they appear one after another when the user returns. This can feel a bit overwhelming compared to showing only the most recent one.

Would love to understand how these cases are currently thought about from a design perspective.