Bug 501350

Summary:	When the mouse cursor hovers over a result, using the keyboard to navigate results does nothing
Product:	[Plasma] krunner	Reporter:	Riccardo Robecchi <sephiroth_pk>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED FIXED
Severity:	minor	CC:	4wy78uwh, alexander.lohnau, cwo.kde, natalie_clarius, nate, ye.jingchen
Priority:	NOR	Keywords:	accessibility, usability
Version First Reported In:	6.3.2
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:	https://invent.kde.org/plasma/milou/-/commit/ed5257558eeb994071be14a9c799d4a34e11e169	Version Fixed/Implemented In:	6.4.0
Sentry Crash Report:

Description Riccardo Robecchi 2025-03-11 12:16:00 UTC

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

Comment 1 Nate Graham 2025-03-11 22:40:51 UTC

Can reproduce.

Comment 2 Bug Janitor Service 2025-03-12 18:33:51 UTC

A possibly relevant merge request was started @ https://invent.kde.org/plasma/milou/-/merge_requests/86

Comment 3 cwo 2025-03-14 07:38:40 UTC

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

Comment 4 Ye Jingchen 2025-03-15 10:40:47 UTC

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.

Comment 5 cwo 2025-03-15 11:24:23 UTC

(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.