Created attachment 157247 [details] typing a search quickly, the bug does not present SUMMARY I'm not exactly sure when it was introduced, but a recent Kickoff bug (within the last couple of major plasma versions) has been bothering me and I finally reproduced it today, but it's not 100% consistent. In summary, if you start a search in Kickoff, typing more in that search may cause the focus to jump to wherever your mouse cursor is pointed, even if you do not move the cursor at all. This leads to selecting the an item other than the one you intended when pressing "enter". STEPS TO REPRODUCE (see attached videos) 1. Click or activate kickoff menu with shortcut key with mouse positioned somewhat over the bottom half of where the kickoff menu will appear 2. Type a few letters of search quickly (enter them before the initial search is returned -- the specifics of this will depend on what items you have enabled in the "Plasma search" settings) 3. Observe that even though your mouse is over an item in the results, the first item is focused 4. Type something else that causes the search order to change -- it appears this only happens for some entries and not others. In my video example, the focus will jump to "KWalletManager", "Citrix Connection Center", "Citrix Workspace Preferences", "Google Chrome", "Grub Customizer", and "Libreoffic Calc", but not the other entries -- interestingly, these appear to be all but the first 5 entires. OBSERVED RESULT Focus jumps to different item than I indented. When working quickly, this sometimes causes the incorrect application or item to be opened when pressing "Enter" EXPECTED RESULT If the mouse is not moved, or keyboard arrows not pressed, Kickoff would only ever open the first search item in the list SOFTWARE/OS VERSIONS Linux/KDE Plasma: kernel 6.1.15-1-lts KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION It appears to only happen if you type more characters after an initial search has been run. Typing very quickly will not reproduce the problem, while typing slowly will. I've also confirmed my mouse is not moving accidentally by completely shutting it off while testing this.
Created attachment 157248 [details] if you type slowly, the issue is apparently
Can reproduce, but it's actually a Qt bug that's already fixed for Plasma 6; see Bug 454349. *** This bug has been marked as a duplicate of bug 454349 ***
I should have mentioned, this happens to me on an X11 session, not Wayland like the marked duplicate. Does that change anything? Mine seems slightly different in that it doesn't persist or involve moving the mouse during the opening/closing Kickoff. It's more that a keyboard entry or the widget changing underneath the mouse seems to make it take focus of whatever the mouse is over at the time.
Hmm yeah, https://codereview.qt-project.org/c/qt/qtdeclarative/+/457096 was a Wayland-specific change. Re-opening.
This is super weird. With the non-compact list style and typing "se" with a delay after the "s" while having the mouse in the region from the 4th item to the last item visible, I am able to consistently reproduce the bug. If I change anything, (the letter combinations, the list style, putting the mouse above the 4th item, not typing with a delay), the bug can no longer be reproduced.
(In reply to Noah Davis from comment #5) > This is super weird. With the non-compact list style and typing "se" with a > delay after the "s" while having the mouse in the region from the 4th item > to the last item visible, I am able to consistently reproduce the bug. If I > change anything, (the letter combinations, the list style, putting the mouse > above the 4th item, not typing with a delay), the bug can no longer be > reproduced. I have a few other combinations that trigger it. Hovering the mouse over the 5th item, "su" and "se" will trigger, while "st", "sa", and "si" will not. Similarly, ("ta", "to", and "th") do not, while ("te", "tr", and "ti") do. My gut feeling is maybe there's something about the item that comes up in that particular spot that triggers the focus switch, rather than the specific letters entered? I should note that this triggered very regularly for me while I had "Desktop Search" enabled, which is where the big annoyance was, because I would often open random files rather than whatever application I was searching for. I never really used that feature, so disabling Desktop Search has been a partial workaround for me, but the issue is still happening (it's just less impactful for my workflow with the workaround).
> My gut feeling is maybe there's something about the item that comes up in that particular spot that triggers the focus switch, rather than the specific letters entered? Possibly. Some of the combinations that worked for you do not work for me while some that didn't work for you work for me. Also, some combinations like "ti" allow me to trigger the bug on all items. At least still nothing happens with the compact list style.
*** This bug has been marked as a duplicate of bug 466192 ***