In openQA we have a desktop notifications test. It boots to runlevel 3, fiddles things so an update is available, then switches to runlevel 5, starts KDE, sits around for 10 minutes, then: 1. Checks that it sees the tray update notification icon (it does) 2. Sees the generic 'ringing bell' tray notification icon, and clicks it, expecting it to open the Notifications view (where it would look for a detailed update notification) Since Fedora-Rawhide-20241016.n.1 , this has broken. Clicking on the 'ringing bell' tray icon makes it go away, but does not open the Notifications panel. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c4424d8d00 landed in Fedora-Rawhide-20241016.n.1 , so I'm tentatively reporting this against qt6.
Created attachment 2056051 [details] what we saw after clicking the 'ringing bell' icon on Fedora-Rawhide-20241014.n.0 (last good compose)
Created attachment 2056052 [details] what we saw after clicking the 'ringing bell' icon on Fedora-Rawhide-20241016.n.1 (first bad compose - odd notifications pane)
Created attachment 2056053 [details] what we saw after clicking the 'ringing bell' icon on Fedora-Rawhide-20241017.n.1 and later (no notifications pane)
Huh, so now I look closer into the history, there's actually two stages to this. In Fedora-Rawhide-20241016.n.1, we did see *some* kinda notifications pane after clicking on the bell, it just didn't look like we expected (no "Updates available" notification). In Fedora-Rawhide-20241017.n.1 and all later composes, we really see *no* notifications pane at all after clicking the ringing bell. It looks like https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d5f08f6a2 landed in that compose, so the changes there may be relevant also.
Still valid.
This seems to be fixed now.