[plasmashell] [Bug 522945] Action buttons in Thunderbird notification no longer close the notification
cat <[email protected]> Wed, 05 Aug 2026 06:30:41 +0000
| Newsgroups | gmane.comp.kde.devel.bugs |
|---|---|
| Message-ID | <[email protected]/> |
https://bugs.kde.org/show_bug.cgi?id=522945 cat <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from cat <[email protected]> --- I reproduced this and traced the root cause, then verified a fix on Plasma 6.7.2 (Debian, Wayland). Below are the details, the fix, and before/after verification. ## Repro (portal/Flatpak path) Send a notification through the notification portal backend (org.freedesktop.impl.portal.desktop.plasmanotify) with a default action and no buttons, from a long-running process (to mimic a Flatpak app): - Clicking the notification body emits ActionInvoked (the action runs), but the notification does NOT close. - This affects both action buttons (invokeAction) and body clicks (invokeDefaultAction), and also reply actions. ## Root cause The portal path drops the Close behavior. In `libnotificationmanager/portalnotificationsmodel.cpp` (a NEW file in 6.7, part of the notification portal rewrite), both methods start with: void PortalNotificationsModel::invokeAction(uint notificationId, const QString &actionName, Notifications::InvokeBehavior behavior) { Q_UNUSED(behavior); // <-- Close behavior dropped here ... Portal::self().invokeAction(notificationId, actionName, actionTarget, {}, window()); } `invokeDefaultAction()` and `reply()` have the same `Q_UNUSED(behavior)`. `Portal::invokeAction()` (portal_p.cpp) only emits ActionInvoked; it never closes the notification. Compare the native (non-portal) path in `notificationsmodel.cpp`, which passes behavior through to `Server::invokeAction()`, and `server.cpp` emits CloseNotification when `behavior & Notifications::Close`. So for any app going through the portal (i.e. Flatpak/sandboxed apps), clicking an action executes it but never closes the notification. This is exactly the reported symptom (Thunderbird from Flatpak). ## Verified fix Make the portal model honor the Close behavior, mirroring the native path. Added a helper in `portalnotificationsmodel.cpp`: void PortalNotificationsModel::closeAfterInvoke(uint notificationId, Notifications::InvokeBehavior behavior) { if (!(behavior & Notifications::Close)) { return; } if (rowOfNotification(notificationId) == -1) { return; } // Portal notifications have no CloseNotification DBus signal of their // own; the model owns the lifecycle (mirrors PortalNotificationsModel::close()). Portal::self().removeNotification(notificationId); onNotificationRemoved(notificationId, Server::CloseReason::DismissedByUser); } and call it after the action in all three methods: Portal::self().invokeAction(...); closeAfterInvoke(notificationId, behavior); Header: added `void closeAfterInvoke(uint notificationId, Notifications::InvokeBehavior behavior);` ## Before / after verification Same machine, same test (portal notification with default action, no buttons, body click): original (unfixed) patched notification 885392 B 962136 B click closes? NO (stays open) YES (disappears) Also verified with a portal notification that has an action button: after the patch the button click closes the notification too. ## Notes - The bug also affects `reply()` on the portal path. - This file/behavior is new in Plasma 6.7; Plasma 6.6 had no portal notification model (portal notifications went through a different path), which is why this regression did not exist before. - Not fixed upstream as of the latest master. -- You are receiving this mail because: You are watching all bug changes.