Bug 407361 - Notifications in the history lack interactive features that are in their pop-ups (click on body to jump to app, clickable buttons, draggable images, etc)
Summary: Notifications in the history lack interactive features that are in their pop-...
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: master
Platform: Other Linux
: HI normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
Keywords: usability
: 414706 429653 438161 441912 453356 (view as bug list)
Depends on:
Reported: 2019-05-09 13:31 UTC by Nate Graham
Modified: 2024-05-30 06:16 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22

Non-interactive notification in history (139.97 KB, image/png)
2019-05-09 13:31 UTC, Nate Graham
Interactive notification pop-up (51.41 KB, image/png)
2019-05-09 13:31 UTC, Nate Graham

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2019-05-09 13:31:27 UTC
Created attachment 119929 [details]
Non-interactive notification in history

New notification system; everything from git master

1. Have updates available in Discover
2. Receive notification about this
3. Ignore or dismiss the notification
4. Click on notification history system tray

The notification history entry for the update is non-interactive; if I click on it, nothing happens, and it has no "Update" button the way the actual notification bubble does

The history entry should be interactive, so I can click on it and go to Discover to see the updated it's telling me about
Comment 1 Nate Graham 2019-05-09 13:31:49 UTC
Created attachment 119930 [details]
Interactive notification pop-up
Comment 2 Nate Graham 2019-06-02 21:11:45 UTC
Actually, I just noticed that KIO's file transfer notifications retain their buttons in the history. Why can't Discover's update notification keep its "Update" button? Is this a Discover bug?
Comment 3 Kai Uwe Broulik 2019-06-03 06:58:58 UTC
These aren't "notification actions" handled by an application but done internally by the notification plasmoid. It just remembers the URL and can then provide the "Open" button and menu.
Comment 4 Nate Graham 2019-06-03 13:18:43 UTC
Hmm, is there any way we can re-use that for Discover? Or would that be a mess?

Alternatively could we just do Bug 407667 instead?
Comment 5 Rick 2019-09-10 02:06:34 UTC
I'm having this issue on Manjaro 18.04. Are there any workarounds to keep notification history with a working link? Is this fixed on Neon or other releases?
Comment 6 Rick 2019-09-10 03:28:10 UTC
In case it's helpful info:

I've noticed that when you get the popup notification that is visible for 5 seconds:

If I click the notification tray during that 5 seconds while it's visible, there is a button under the notification that says 'Activate'. If you click the 'Activate' button, it will take you to the correct link. If you wait for the popup to go away, the activate button will no longer be available, and you will not get a relevant link.

I have also noticed a minor difference between Chromium and Firefox:

When I subscribe to the push notifications in Chromium, I do get a link to the root of the website. In Firefox, there is no link at all.
Comment 7 Nate Graham 2019-12-02 21:05:49 UTC
*** Bug 414706 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2019-12-02 21:06:30 UTC
If this is a restriction of the spec, we should consider trying to amend the spec to accommodate it.
Comment 9 postix 2020-01-24 19:08:07 UTC
Is there a way to support buttons in the history for GTK apps notifications? 

Background: I got an invite within a chat app (Dino) which was displayed as a notification popup with two buttons: Accept and reject. However, when I waited too long the notification was gone and the history gave me no chance to react to the invite. :-/
Comment 10 Bernd 2020-08-18 16:37:08 UTC
This makes the entire "push notifications" thing browsers have nowadays pretty much useless. Why do I need web notifications when I can't click them? 

Is there any workaround, maybe an alternative notification history applet/plasmoid/whatever that does NOT strip the clickable links from the notifications?
Comment 11 Nate Graham 2020-12-01 18:09:12 UTC
*** Bug 429653 has been marked as a duplicate of this bug. ***
Comment 12 soredake 2020-12-17 18:06:31 UTC
Any progress on this?
Comment 13 Kai Uwe Broulik 2021-03-14 19:03:07 UTC
Git commit a01c7813b91406e4419a4eb43870b1698f7bf78e by Kai Uwe Broulik.
Committed on 14/03/2021 at 19:02.
Pushed by broulik into branch 'master'.

[Notifier] Use resident notification

This way the "Show updates" button remains usable when the notification expired.

M  +0    -1    libdiscover/resources/discoverabstractnotifier.notifyrc
M  +1    -0    notifier/DiscoverNotifier.cpp

Comment 14 Nate Graham 2021-03-25 19:22:25 UTC
We now have a generic opt-in system for this, but apps need to opt in. Discover already has. So let's mark this as fixed
Comment 15 Patrick Silva 2021-06-06 22:41:37 UTC
*** Bug 438161 has been marked as a duplicate of this bug. ***
Comment 16 Lyubomir 2021-06-07 08:06:04 UTC
In https://invent.kde.org/frameworks/knotifications/-/merge_requests/35 i see the text "let's not make this public API until we know for sure this is what we want". So - is this feature safe to be implemented by 3rd party apps or not yet?
Comment 17 Kai Uwe Broulik 2021-06-07 08:20:48 UTC
It just means there's no proper public method or flag to set it in the KNotification class. Any app can just send this hint along and will work just fine.
Comment 18 Kai Uwe Broulik 2021-10-20 19:41:20 UTC
*** Bug 441912 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2021-10-20 22:30:40 UTC
Kai, for any notifications that are still not interactive in the history view, what needs to be done to fix that?
Comment 20 Nicolas Fella 2022-05-04 11:06:10 UTC
*** Bug 453356 has been marked as a duplicate of this bug. ***
Comment 21 Nicolas Fella 2022-05-04 11:08:03 UTC
> Kai, for any notifications that are still not interactive in the history view, what needs to be done to fix that?

they need to pass the 'resident' hint
Comment 22 Quinten Kock 2022-07-19 21:26:25 UTC
I think this issue deserves reopening, since what KDE does is different from other projects (such as GNOME). On GNOME, I can click a Telegram Desktop notification that disappeared into the notification drawer on the panel. On KDE, that does not work.

On a related note, even for Discover, which keeps a button in the history, clicking the body of the notification does not work, while this does work for the active notification.
Comment 23 Ahmed 2022-07-20 12:37:53 UTC
Cinnamon DE also has interactive notifications. Closing this issue means that there are no intentions to fix it.
Comment 24 Nate Graham 2022-07-20 14:23:04 UTC
The feature in question was implemented, but apps need to opt into it. It's not done for all apps by default automatically.

If you think that should happen, please file a new bug report for it, so we can discuss it separately.
Comment 25 Bharadwaj Raju 2022-10-13 07:41:41 UTC
So do other DEs simply not care about the resident hint or what? If it's not causing them any problems maybe we should do the same.
Comment 26 Carlos Solís 2022-10-13 14:02:27 UTC
Regarding the specifications ( https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#hints ), they use two different boolean values, `resident` and `transient`. The first states that "The notification will remain resident in the server until it is explicitly removed by the user or by the sender", but doesn't clarify whether that means "visible on screen until dismissed" or "held on the notifications tray until dismissed". The second boolean, however, leads me to believe there is a difference between them, as a transient notification will "by-pass the server's persistence capability, if it should exist."  The specs seen to leave the implementation for notifications not marked as either transient or resident (that is, the default) up to each specific server's implementation.
Comment 27 Akarshan Biswas 2024-05-30 06:11:02 UTC
I don't think this is resolved or fixed even in 6.0.5. If a notification is from app like telegram, it is still not "clickable" in the notification history applet and the app doesn't launch.