SUMMARY When invoking KRunner, the mouse takes precedence over everything else when determining which result should be highlighted. This means that using the keyboard to navigate between results is impossible if the mouse cursor happens to be hovering over one of them. As an example of why this is inconvenient and unwanted behaviour, you might have the mouse cursor in the middle of the screen and invoke KRunner; at that point you can't navigate between results using your keyboard because the mouse cursor is already there and prevents it, even though it was never your intention to use it to select a result. STEPS TO REPRODUCE 1. Invoke KRunner 2. Move the mouse cursor on a result 3. Try to move between results using the keyboard OBSERVED RESULT Nothing happens. EXPECTED RESULT The keyboard takes precedence over the mouse and the highlighted result changes according to keyboard input. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION
Can reproduce.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/milou/-/merge_requests/86
Git commit ed5257558eeb994071be14a9c799d4a34e11e169 by Christoph Wolk. Committed on 12/03/2025 at 18:45. Pushed by cwo into branch 'master'. lib: simplify mouse hover handling ResultsView/ResultDelegate do some complicated mouse interaction handling: the delegate listens to a HoverHandler's pointChanged signal. which updates in a lot of circumstances, and then filters based on keeping track whether the mouse moved to not activate with keyboard-only use. This doesn't work well if there is mixed keyboard/mouse use, where arrow key navigation becomes useless almost as soon as the mouse is involved. And it isn't really necessary in the first place, as the real problem is connecting to such a busy signal. Instead, we drop the whole state-tracking jazz and even the HoverHandler, and just listen to the delegate's own hovered property. hovered only updates after the mouse moves, so we get essentially the same thing for free but without the edge case bugs. FIXED-IN: 6.4.0 M +1 -6 lib/mousehelper.cpp M +0 -2 lib/mousehelper.h M +6 -13 lib/qml/ResultDelegate.qml M +0 -9 lib/qml/ResultsView.qml https://invent.kde.org/plasma/milou/-/commit/ed5257558eeb994071be14a9c799d4a34e11e169
IMHO krunner could borrow what Firefox does: in Firefox the address bar dropdown has separate keyboard and mouse selection, represented by colored and gray background, and responds to enter key and mouse click correspondingly.
(In reply to Ye Jingchen from comment #4) > IMHO krunner could borrow what Firefox does: in Firefox the address bar > dropdown has separate keyboard and mouse selection, represented by colored > and gray background, and responds to enter key and mouse click > correspondingly. Ideally, I think we'd want to go in that direction (I certainly do), but we need to figure out precise guidelines for what exactly the states should be, how all they should look like in all the relevant circumstances, and then implement that across the stack (which would likely involve both the general components/styles and many parts of individual apps and applets). Very desirable, but also a lot of work to do consistently.