Bug 513275

Summary: Notification doesn't popup again when being replaced
Product: [Plasma] plasmashell Reporter: Weng Xuetian <wengxt>
Component: NotificationsAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: equeim, kde, nate, naxdy
Priority: NOR Keywords: regression
Version First Reported In: 6.5.4   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Weng Xuetian 2025-12-13 00:50:55 UTC
SUMMARY
Not sure since which version, but now notification doesn't popup up again when being replaced.

STEPS TO REPRODUCE
previous=`notify-send -p  -t 4000 TEST TEST` ; sleep 5; notify-send -r $previous -t 4000 TESTA TESTB 

OBSERVED RESULT
TESTA / TESTB doesn't show up

EXPECTED RESULT
after timeout, while the notification is still in history, the new replace will be able to make it popup so user can see it.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Comment 1 Nate Graham 2025-12-16 22:15:09 UTC
Can reproduce.
Comment 2 equeim 2026-01-10 23:40:15 UTC
I think this is technically a violation of notifications spec. You are not supposed to use again id of expired or dismissed notification. Though we already show notification again if was replaced after being dismissed, it wouldn't be hard to do the same for expired ones.
Comment 3 equeim 2026-01-11 00:06:54 UTC
Now I wonder, should we show two entries in history if user lets this second notification expire too? I.e. should it act as a new notification or not?

There may be trouble with notification ids. We keep track of notifications by their ids, and that includes notifications in history too. So if we want to show this new notification separately then it must have a different id. However we can't do that because notifications spec says that Notify method returns replaces_id if it wasn't zero.
Comment 4 equeim 2026-01-11 00:21:35 UTC
(In reply to equeim from comment #3)
> Now I wonder, should we show two entries in history if user lets this second
> notification expire too? I.e. should it act as a new notification or not?
> 
> There may be trouble with notification ids. We keep track of notifications
> by their ids, and that includes notifications in history too. So if we want
> to show this new notification separately then it must have a different id.
> However we can't do that because notifications spec says that Notify method
> returns replaces_id if it wasn't zero.

Maybe we should just return an error over D-Bus in such cases? The spec says that you should do so in CloseNotification if it doesn't exist but we don't do that either. It says nothing what to do if replaces_id refers to non-existent notification. Looking through GNOME's source code it seems that's what they do.
Comment 5 Bug Janitor Service 2026-01-11 00:40:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6168
Comment 6 Bug Janitor Service 2026-01-11 00:40:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6168
Comment 7 Kai Uwe Broulik 2026-01-29 16:42:55 UTC
This is intentional.