Bug 506633 - Notifications with actions never close upon expiry even when they don't go to history
Summary: Notifications with actions never close upon expiry even when they don't go to...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (other bugs)
Version First Reported In: 6.4.0
Platform: Other Other
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2025-07-05 12:38 UTC by Martin
Modified: 2025-08-06 23:28 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2025-07-05 12:38:20 UTC
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178

This PR made it that notifications with actions that expire automatically are never announced as closed until the PID that sent them closes.

This completely broke my application that waits for a close event from the notifications it sends. 

One can repro this with sdbus and python while listening to dbus to see close notifications. 

I understand the point behind the PR but it should not apply to notifications which do not end up in history.

#!/usr/bin/env python
"""gdbus monitor --session --dest org.freedesktop.Notifications --object-path /org/freedesktop/Notifications"""
from __future__ import annotations

import time

from sdbus_block.notifications import FreedesktopNotifications as FreedesktopNotifications_blocking

notifier = FreedesktopNotifications_blocking()

# Works
actions = []
notifier.notify( app_name='Nyx', summary="foo", body="abc", expire_timeout=1500, actions=actions, hints=notifier.create_hints(urgency=1))
# Broken
actions = ['test', 'Test']
notifier.notify( app_name='Nyx', summary="foo", body="def", expire_timeout=1500, actions=actions, hints=notifier.create_hints(urgency=1))
while True:
  time.sleep(500)
Comment 1 Martin 2025-07-07 09:36:33 UTC
To add some context - my application waits for the close event to send another notification, to not spam them.

I have added a workaround in my code to ignore the notification state and only rely on the timer (which is wrong, as the notification can be interacted with and expiry will be longer).

The current state will still send hundreds/thousands of close events upon closing of my app, none of which are in the notification history.
Comment 2 dehe_tian 2025-07-12 00:48:20 UTC
Notifications that are not shown in the history seem to have just been hidden. You can make them visible in the history through this setting:
https://forum.manjaro.org/t/no-notification-history/142344/5
Comment 3 Nate Graham 2025-08-06 23:03:44 UTC
We can probably special-case this to expire notifications that won't end up in the history, but I'm not sure if that might be more confusing for developers than the status quo.
Comment 4 Martin 2025-08-06 23:22:38 UTC
Current status is *horrible*.

I was controlling notifcations from the app, to not send more than one if one already exists, Plasma 6.4 completely broke that functionality.

Now I have to rely on timeout of the notification and assume it was closed then, but that does not hold true, user can hover over the notification, or be in Do Not Disturb where the notifications do not expire.

I think a solution here, provided this behavior is desired to be kept, would be to respect things that do not end up history, and developers could then use the "transient" hint to avoid this tar trap.

https://specifications.freedesktop.org/notification-spec/latest/hints.html
Comment 5 Nate Graham 2025-08-06 23:28:46 UTC
Yeah, that sounds reasonable to me.

If you'd like to have a go at implementing that, please feel free!