SUMMARY (Bug also affects the main KDE launcher) STEPS TO REPRODUCE 1. Open Krunner 2. type something 3. move mouse until it hovers over a different result 4. Hit enter OBSERVED RESULT Krunner launches whatever the mouse is hovering over after hitting Enter. EXPECTED RESULT It should always launch the first result (which can perhaps be highlighted in a special way). If someone wants to use the mouse, they can click. Enter is for keyboard launch, and keyboard launch should not be affected by mouse movements. In particular, this problem makes Krunner work especially poorly with trackpoints, because trackpoints have a tendency to move around completely unattended, even without accidental touches.
Maybe the solution is to keep the standard highlight effect for keyboard entry, and use a special hover effect for mouse selection.
Having two different highlights (mouse vs keyboard) would be super weird, nonstandard, and confusing. Silently remembering the keyboard selection but not showing it when the cursor moved over something else likewise would be very surprising behavior and I guarantee that we would get bug reports about that. I think we just need to leave this as it is. Note that in Plasma 5.23, the height of the list items has been made slightly taller, so it should be more difficult to accidentally move the cursor over other entries. Side note: > trackpoints have a tendency to move around completely unattended, even without > accidental touches. My trackpoint doesn't do this. I thikn you are experiencing a bug in Libinput, or a hardware failure. And in general it doesn't make sense to work around those in KDE software. :)
You either have a different trackpoint or don't use it enough to notice. It's a hardware issue with the lenovo trackpoints (it's just how the rubber gets deformed and then gets back its former shape). But the fundamental point is that accidental mouse movements should not interfere with the behavior of a keyboard-based launcher. This is clearly a KDE UX issue. Other GUIs never have this problem because they sensibly separate keyboard input from mouse input, precisely to avoid this issue. Don't believe me? Take a look at Chromium's omnibar. Move the mouse there and press enter. It will still launch the entry you've selected with your keyboard, irrespective of where the cursor happens to be. This is the logical behavior and it's how other launchers behave too, thus avoiding the problem entirely. They aren't wrong. IF you remember, for ages Krunner would actually open whatever entry the mouse was hovering over, even without movement. It was later partially "fixed" by requiring movement, but the original design which was the actual source of the problem was kept The only consequence of KDE's design of mixing keyboard and mouse input is unintended launches. Is causing accidental launches "intended behavior"? Cause that's the only feature the current design provides. So please reconsider.
Try firefox address bar too, btw. It behaves like Chromium. So these are very well charted waters in UX design.
Thanks for the additional information.
Welcome, glad to help.
If you can reproduce the behavior and agree that it's problematic, could you change the status to confirmed (or whatever the appropriate label is)?
Manjaro Plasma user here! I think this is close enough to be the same issue. I'll happily open a new issue if it's not: - Place the mouse cursor over the area where Application Launcher would open - Open the Application Launcher (Super key) - Type a search Expected behavior: - The topmost search item is selected and launched with Enter Actual behavior: - The item under the mouse cursor (which has not moved) is selected and launched with Enter This forces me to select the application with mouse, or move mouse away before opening the menu. I would also consider this as a 15-minute bug, since this could be one of the first things that a user does after booting the system.
Building on Matti's observation: FYI, this behaviour seems to have made its way into Debian Testing, now. For example, I boot my computer, log in to a new plasma session, hit Alt+Space, and type "falkon". I have not touched my mouse at all by this point - it's still centred on the screen. But for whatever reason, krunner selects the item under the mouse (some text file) instead of the top item (the actual falkon app), and if I hit Enter, the text file is what krunner gives me. This took all of 30 seconds to hit. Now every time I use Alt+Space I have to consciously ensure the mouse cursor is outside the drop-down region. This isn't ideal for a tool that's primarily keyboard driven.