Created attachment 175755 [details] Screencapture of the current behavior SUMMARY Currently when an item in the panel has a popup tooltip open by hovering over it, the tooltip switches to the next item immediately when the cursor touches another item. This often leads to multiple tries, to change the open window inside a window group, using the mouse. Or when trying to use the mouse to configure a plasmoid. STEPS TO REPRODUCE 1. Have different plasmoids or applications next to each other 2. Move your mouse over a target with an interactive popup 3. Move your mouse to the popup, slightly "touching" an item next to your desired target OBSERVED RESULT As soon as the cursor touches another target, the popup/tooltip is replaced by one of the other targets. EXPECTED RESULT The original tooltip should only switch to the next target after a short delay (don't know, maybe something between 10 and 100 ms). That would allow to easily reach the interactive popup. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.6-zen1-1-zen (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION
This was a bug in the triangle filtering that's fixed already in Plasma 6.3.
Created attachment 178250 [details] Recording of the behavior with Plasma 6.3 Unfortunately the behavior is still unchanged. Touching another item still immediately causes the popup to disappear.
Mhh, I cannot reproduce here
Does this reproduce in a new clean user account?
Created attachment 179776 [details] Recording in current kde neon testing For me this reproduces on at least two devices. One has Endeavour OS, the other has Garuda OS installed. Can also reproduce this in the latest KDE Neon Testing ISO, see the attachment. The recording is from a vm, but can boot the ISO from a real device later and make another recording, if needed.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
Not sure what other information I can provide. As written in comment #5, for me this reproduces on several devices, even inside a vm started with KDE Neon ISO. If I can provide anything else, please let me know.
I can reproduce it too on current git master. Marking as confirmed.
Created attachment 180231 [details] Illustration of possible cause I think this is the way it fails (see the third and subsequent attempts in this recording). That is, the mouse moves slightly backwards (or otherwise outside the triangle from the current position), and thus the triangle doesn't get "established" before it reaches the other square, and the hover passes onto it. Maybe we could try and alleviate this by starting the triangle even further to the other side of the mouse position than we do currently? I don't know how much we'd have to increase it by. The current value we ship is 1px, and this recording has it set to 5px and it helps but clearly still happens. I'm also idly wondering if we should do away with triangles and instead rely on something simpler like a moving average direction of travel. So as long as you're moving towards the edge, no matter with what slope, it will keep the opened item stable. I'll try see if it's a viable idea.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5393
Git commit 99e0cdefd4d67e2527c3eb54809305c200247a77 by Nate Graham, on behalf of Bharadwaj Raju. Committed on 11/08/2025 at 15:52. Pushed by ngraham into branch 'master'. trianglemousefilter: Fix jitter accounting for top and bottom edges, and increase jitter threshold Since we want the jitter threshold to extend the triangle's starting point in the *opposite* direction from edge, that means for top(/bottom) edges, it should increase(/decrease) the y of the starting point. Until now the code had been doing the opposite. Also, increase the jitter threshold to 5px. M +2 -2 components/trianglemousefilter/trianglemousefilter.cpp M +1 -1 components/trianglemousefilter/trianglemousefilter.h https://invent.kde.org/plasma/plasma-workspace/-/commit/99e0cdefd4d67e2527c3eb54809305c200247a77