Repository navigation
Notification popup stays in the middle of the screen after hover #1887
Description
Activity
- addedfeature requestNew feature or requestNew feature or requestand removedbugSomething isn't workingSomething isn't working
on Mar 2, 2026 I wouldn't label this a bug, or even make a change here I don't think. When you hover, it stops in place to respect what you're doing to read it. After release, it go goes away with the time left. Making it jump again my be jarring but I'll take it into consideration
I thought it looked odd, only after a couple seconds I realized that it was probably due to my hover.
I guess it’d make sense to check how other platforms deal with it - gnome, elementary, macOSWell, on macOS they have changed the notification system to never show more than 1 at a time (which might be a good idea btw).
We definitely aren't gonna go the MacOS route. I think this is more user preference than anything. Ours shows up to 4 and starts stacking and now you know why it would stay in place on hover. Not sure anything will change from here.
This behavior is confirmed to be fully resolved in the current v1.5-beta branch, specifically addressed by commit
c554d973authored by @purian23.I conducted a series of automated stress tests to evaluate the asynchronous lifetime cross-over and accumulation limits of the notification stack on a tiling compositor environment.
Test Environment:
- DMS Shell: v1.5-beta (
~/.config/quickshell/dms/) - Quickshell: 0.3.0 (Debian package)
- Compositor: Niri (
niri --session) viawayland-1 - OS: Debian GNU/Linux forky/sid (Kernel 6.19.14)
Test Scenario (Asymmetric Accumulation & Staggered Expirations):
# 5 notifications dispatched at 3-second intervals, 15s TTL each notify-send "SRE Monitor" "Active capture" -t 15000 & sleep 3 notify-send "Slack B2B" "Mention from @bbedward" -t 15000 & sleep 3 notify-send "PipeWire" "Handshake successful" -t 15000 & sleep 3 notify-send "D-Bus Router" "Queue full (4)" -t 15000 & sleep 3 notify-send "Systemd User" "Background queued (5)" -t 15000
Observed Behavior:
- Notifications accumulated orderly up to the strict limit of 4 active popups.
- The 5th payload stayed securely queued in memory as a background wrapper.
- Upon expiration of the oldest popups, the remaining surfaces instantly triggered a fluid slide-up cascade animation to claim the newly cleared Y-coordinates.
- The queued notification materialized seamlessly into the available bottom slot.
Code Verification:
The fix introduced in
c554d973breaks the race condition by adding thecontextMenuActiveguard to intercept ghost timer initializations post-hover release. Additionally,_sync()stabilization via_isFocusedScreen()prevents out-of-focus screen states from bleeding into the active stack vertical geometry model. Combined with the micro-task scheduling safety ofQt.callLateron state mutations, the layout engine now consistently collapses dead space without leaving stuck layer-shell windows floating in the middle of the screen.This issue can be safely closed as completed.
- DMS Shell: v1.5-beta (
Compositor
Niri
Distribution
Fedora
If Other, please specify
No response
Select your Installation Method
DankInstaller
Was this your original Installation method?
Yes
If no, specify
No response
dms doctor -vC
Click to expand
DMS Doctor Report
System
Versions
Installation
Compositor
Quickshell Features
Optional Features
Config Files
Services
Environment
Summary: 0 error(s), 0 warning(s), 32 ok
Description
When multiple notifications appear, and you hover over one at the bottom, it will stay there, even after the top notifications disappear, and you stop hovering it.
Expected Behavior
The notification should move up when user stops hovering it, and there's free space above.
Steps to Reproduce
Error Messages/Logs
No response
Screenshots/Recordings
Screencast.From.2026-03-02.10-08-25.mp4