Summary
On the notification popup, left-clicking the card body only invokes the first action when the body text is short enough to fit. When bodyText.hasMoreText is true (long body), the click expands the description instead — so notifications with longer bodies and at least one action can only be acted on by clicking the visible action button(s), not the body itself.
This is most visible with Slack notifications routed through xdg-desktop-portal-gtk: the body text is almost always long enough to be "expandable", so clicking the notification body never invokes Slack's primary action, and the only way to act on a Slack notification is to click its Open button.
Reproduction
- Receive a notification with a body long enough that
bodyText.hasMoreText is true, and at least one action (a typical Slack DM does this).
- Left-click anywhere on the notification body (not on an action button).
- Observed: the popup expands its description.
- Expected (or at least configurable): the first action is invoked, dismissing the notification and triggering the source app's handler.
Relevant code
quickshell/Modules/Notifications/Popup/NotificationPopup.qml, around the cardHoverArea MouseArea onClicked handler (~L1050 on master):
} else if (mouse.button === Qt.LeftButton) {
const canExpand = bodyText.hasMoreText || win.descriptionExpanded ||
(SettingsData.notificationPopupPrivacyMode && win.hasExpandableBody);
if (canExpand) {
win.descriptionExpanded = !win.descriptionExpanded;
} else if (notificationData.actions && notificationData.actions.length > 0) {
notificationData.actions[0].invoke();
NotificationService.dismissNotification(notificationData);
} else {
notificationData.popup = false;
}
}
canExpand always wins over the action branch when the body is long.
Suggested fix
Add a SettingsData toggle (e.g. notificationPopupBodyInvokesAction, default false to preserve current behavior) and rearrange the branches so the action invocation wins when the toggle is on:
const hasAction = notificationData.actions && notificationData.actions.length > 0;
if (SettingsData.notificationPopupBodyInvokesAction && hasAction) {
notificationData.actions[0].invoke();
NotificationService.dismissNotification(notificationData);
} else if (canExpand) {
win.descriptionExpanded = !win.descriptionExpanded;
} else if (hasAction) {
notificationData.actions[0].invoke();
NotificationService.dismissNotification(notificationData);
} else {
notificationData.popup = false;
}
This keeps the expand-on-long-body behavior as the default, but lets users opt into "body click acts as default action" — useful on Wayland setups where the only way to bring an app's window forward in response to a notification is through the action handler (the app itself can't raise on Wayland).
Environment
- DMS installed via the danklinux installer
- Quickshell
0.3.0
- Compositor: niri (Wayland)
- Distro: Fedora 44
Summary
On the notification popup, left-clicking the card body only invokes the first action when the body text is short enough to fit. When
bodyText.hasMoreTextis true (long body), the click expands the description instead — so notifications with longer bodies and at least one action can only be acted on by clicking the visible action button(s), not the body itself.This is most visible with Slack notifications routed through
xdg-desktop-portal-gtk: the body text is almost always long enough to be "expandable", so clicking the notification body never invokes Slack's primary action, and the only way to act on a Slack notification is to click its Open button.Reproduction
bodyText.hasMoreTextis true, and at least one action (a typical Slack DM does this).Relevant code
quickshell/Modules/Notifications/Popup/NotificationPopup.qml, around thecardHoverAreaMouseAreaonClickedhandler (~L1050 on master):canExpandalways wins over the action branch when the body is long.Suggested fix
Add a
SettingsDatatoggle (e.g.notificationPopupBodyInvokesAction, default false to preserve current behavior) and rearrange the branches so the action invocation wins when the toggle is on:This keeps the expand-on-long-body behavior as the default, but lets users opt into "body click acts as default action" — useful on Wayland setups where the only way to bring an app's window forward in response to a notification is through the action handler (the app itself can't raise on Wayland).
Environment
0.3.0