[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.