There are two issues with kickoff regarding mouse placement. That is, the location where your mouse cursor is inactive while typing into the search box. I have recorded a screen demo of both issues, this is reproducible. Issue 1: If the cursor is positioned in the bottom-left corner of kickoff, the search does not work at all. Issue 2: If the cursor is positioned over the search results area, while you're typing, the result underneath the cursor is the item that gets chosen when you finally press Enter. It should always launch the most relevant search result at the top of the list when you press Enter. I run into these problems very often, because I usually click the launcher icon, then move my hands over to the keyboard to start typing. So my mouse cursor usually lays to rest somewhere on top of the menu. Screen recording: https://www.youtube.com/watch?v=6wDR4rtgxuo Note: In the video, I am using adapta and some other custom styling, but I tested with all default Breeze and the same issues were present. Linux/KDE Plasma: KDE Neon (available in About System) KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2
Regarding Issue 2: duplicate of https://bugs.kde.org/show_bug.cgi?id=397693
Can confirm issue #1 in 5.14.4 and git master. Very odd. Possibly related to the recent single mousearea patch?
(In reply to Nate Graham from comment #2) > Can confirm issue #1 in 5.14.4 and git master. Very odd. Possibly related to > the recent single mousearea patch? Thanks for taking a look. I just double-checked something, it's not just the bottom-left corner. It's the entire horizontal space under the large icons at the bottom (below Favorites/Applications/Computer/History/Leave). There's about a 20 pixel-high strip below those icons where search doesn't work. That might make it slightly less puzzling than just one single corner.
Yep, that makes more sense to me too.
Can confirm. The "Search Results" page technically is another Tab pushed into page stack. When the mouse rests (I think it has to move) over the tab bar while the search page enters, you end up accidentally switching to another tab. Likely bug exposed by the tab bar no longer having a delay before it switches tabs.
*** Bug 402423 has been marked as a duplicate of this bug. ***
Confirmed in 5.15.3. One of the most annoying bugs I've ever dealt with as it sometimes requires reopening kicker multiple times before search starts to work correctly. But that's my use case, since I open the menu with a keybind and the mouse doesn't move doing so.
I did some poking around. The bug is not reproducible before this commit: https://github.com/KDE/plasma-desktop/commit/62f92fd822efb059a07dd77c93158ecba73d1ced#diff-5ab15790503cdc8b5d9ba1fff5cebec2 After removing line 524 ("button.clicked();") in master version of FullRepresentation.qml, the problem goes away. See: https://phabricator.kde.org/D21978
Nice find! I hope you use `git bisect` for that. :) If you didn't, or you don't know how to use it, let me show you tomorrow!
Patch https://phabricator.kde.org/D21988
Git commit 0628dab8f42ba0d4c4acdb6004d8e5ad98bfdb52 by Eike Hein. Committed on 22/06/2019 at 11:04. Pushed by hein into branch 'Plasma/5.16'. Reject duplicate events with identical coordinates Summary: BUG:401861 Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D21988 M +6 -0 applets/kickoff/package/contents/ui/FullRepresentation.qml https://commits.kde.org/plasma-desktop/0628dab8f42ba0d4c4acdb6004d8e5ad98bfdb52
I'm still experiencing this bug with 5.16.3, see video. Reproduced in master as well.
Created attachment 121521 [details] Bug still present in 5.16.3
*** Bug 411678 has been marked as a duplicate of this bug. ***
You can turn off the "Switch tabs on hover" option to work around this. The other solution with removing the "button.clicked()" line I did in that patch above also works well, I have been using that for some time now.
*** Bug 415338 has been marked as a duplicate of this bug. ***
*** Bug 401365 has been marked as a duplicate of this bug. ***
*** Bug 404655 has been marked as a duplicate of this bug. ***
*** Bug 415314 has been marked as a duplicate of this bug. ***
*** Bug 420282 has been marked as a duplicate of this bug. ***
Patch: https://phabricator.kde.org/D28985
Git commit 020c67fc8ba30240215f498eb8106635b05ecd04 by Nate Graham, on behalf of Tranter Madi. Committed on 20/04/2020 at 14:16. Pushed by ngraham into branch 'Plasma/5.18'. [Kickoff] Disable tabBar's mouseArea when searching Summary: When the root is in the "Search" state, we can safely disable it. Reviewers: #plasma, hein, ngraham, davidedmundson Reviewed By: #plasma, ngraham, davidedmundson Subscribers: davidedmundson, ngraham, bugseforuns, dginovker, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D28985 M +1 -0 applets/kickoff/package/contents/ui/FullRepresentation.qml https://commits.kde.org/plasma-desktop/020c67fc8ba30240215f498eb8106635b05ecd04
*** Bug 420759 has been marked as a duplicate of this bug. ***