Created attachment 149964 [details] Video demo where I press only Meta, Down, Down, Down, Down SUMMARY When selecting Kickoff menu items with the keyboard, the item under the mouse is repeatedly selected even though I moved the selection with the Down key. This seems to happen only on the first few menu options. STEPS TO REPRODUCE 1. Open kickoff 2. Move the mouse to hover over "Favorites" 3. Press the Down arrow to select "All Applications" 4. Wait 500ms. OBSERVED RESULT After a short delay "Favorites" becomes selected again. This happens repeatedly. That is, if I press Down again, the selection moves briefly to "All Applications" and then, after about 500ms, it moves back to "Favorites". If I press Down two times in quick succession, though, the selection stays where it should. Then I can press Up to move back to "All Applications" and it will stay. If I then move the selection back up to "Favorites", though, the effect resumes. Pressing Down moves to "All Applications" but the selection moves back to "Favorites" after 500ms. EXPECTED RESULT Keyboard selection should override mouse cursor selection until I move the mouse again. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE neon 5.25 KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION The problem also occurs if I highlight "All Applications" with the mouse cursor and then try to move up or down using the keyboard. The "All Applications" item keeps getting selected 500ms later. This doesn't appear to happen with any other menu options, though. A similar problem happens with the Search results menu. I'm not sure if this is a separate bug. 1. It affects the first three search results, not only the first two. 2. The selection reverts to the mouse-hovered one much faster, about 200ms. 3. It only happens if I never move the mouse while results are displayed. 4. It is not repeatable. That is, a. Press the arrow once to move selection away. b. 200ms later selection moves back to mouse. c. Press the arrow again to move the selection away. d. The selection stays where it should now. Seems like it might be related to #447278
Comment on attachment 149964 [details] Video demo where I press only Meta, Down, Down, Down, Down I did only press Down first half of the recording. But I pressed Up two times to return to "Favorites" at the midpoint where I managed to move two selections away. Then I only pressed Down again.
Is this a new problem or has the problem been around for a few releases?
(In reply to Noah Davis from comment #2) > Is this a new problem or has the problem been around for a few releases? I don't know. I only noticed it today when I encountered the 2nd described problem (search weirdness). My mouse had to be in just the right spot to cause the problem. My guess is that it has been around for a while, based on similar-sounding https://bugs.kde.org/show_bug.cgi?id=398151 I'll try to repro on the liveCD version later.
Bug 398151 is unrelated since it's a different menu. I'm mainly curious if it could be related to a recent change where we tried to switch to a more performant way of detecting when a mouse was hovering over an item.
We fixed this ages ago in the old Kickoff, then IIRC again in the new one, and I guess it's broken again.
*** Bug 455724 has been marked as a duplicate of this bug. ***
(In reply to Noah Davis from comment #4) > Bug 398151 is unrelated since it's a different menu. I'm mainly curious if > it could be related to a recent change where we tried to switch to a more > performant way of detecting when a mouse was hovering over an item. Yep, it seems it is. For whatever reason an "entered" signal is being emited even if there was not enter at all, and only for the first item in case of current view or for any item in case of moving to different view. Not sure if it's a Qt bug or some Kickoff design flaw, but something tells me "entered" should not work like that.
(In reply to Artem Grinev from comment #7) > (In reply to Noah Davis from comment #4) > > Bug 398151 is unrelated since it's a different menu. I'm mainly curious if > > it could be related to a recent change where we tried to switch to a more > > performant way of detecting when a mouse was hovering over an item. > > Yep, it seems it is. For whatever reason an "entered" signal is being emited > even if there was not enter at all, and only for the first item in case of > current view or for any item in case of moving to different view. Not sure > if it's a Qt bug or some Kickoff design flaw, but something tells me > "entered" should not work like that. Technically, it is being entered, just not by moving the mouse to the item. Rather, it is the item that is being moved to the mouse and detecting the presence of the mouse. The worse performing onPositionChanged signal handler that we were using happened to not detect the mouse unless the mouse was moved, but I'm not advocating for switching back unless it's impossible to fix this otherwise.
Attaching a video showing similar issue: wrong menu item got selected even without hovering mouse cursor. Please let me know if it's a separate issue and I have to create a new bug report. I'm not sure. Vid: https://drive.google.com/file/d/12VCAvgZ33gvDQHbvVApflJvhHa5WLwKq/view?usp=sharing
*** Bug 455972 has been marked as a duplicate of this bug. ***
(In reply to Komorebi from comment #9) > Attaching a video showing similar issue: wrong menu item got selected even > without hovering mouse cursor. > Please let me know if it's a separate issue and I have to create a new bug > report. I'm not sure. > Vid: > https://drive.google.com/file/d/12VCAvgZ33gvDQHbvVApflJvhHa5WLwKq/ > view?usp=sharing How strange. It could be a separate bug, but I'm not sure how this would have happened. I can't reproduce it just by typing "sys" like you did, but I suppose that's because I don't know the true cause.
I've forked kickoff in order to implement https://bugs.kde.org/show_bug.cgi?id=455724 (test version is here: https://github.com/komorebithrowsatable/org.kde.plasma.kickoff.fixed), and it seems like this behavior is a result of 2 bugs. I seems like when you run one of you favorite apps (which are located in grid view) with mouse click, MouseArea don't emit exited() event and behaves like the mouse pointer is still there even after Kickoff is closed. But it looks like it's a deeper Qt bug that causes "phantom" mouse pointer to stay on the last position until you hover Kickoff with a real pointer once again. In combination with this bug this leads to the behavior shown in the video - "phantom" cursor selects an element from the bottom during the animation. So fixing this bug probably may also resolve bug from the video, at least for the current Kickoff version. But it also effects my version of Kickoff and probably some other alternative solutions, which means it can cause some issues with Plasma in future. To reproduce: 1. Run wayland session 2. Run app from the "favorites" grid 3. Try to search In this video you can see how item remains highlighted till I move mouse to Kickoff: https://drive.google.com/file/d/141mVx-tELYUwNykA1Z7lop9wXPOPo1EV/view?usp=sharing I'm attaching demo with my kickoff just because it illustrates the issue a way better.
Created attachment 150271 [details] Settings icon is focused without cursor I see the same behavior in other widgets, see the settings button is focused without mouse pointer. Shall I create a separate bug report?
*** Bug 456231 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1074
Git commit cfb520e3b39714edb6e9d406bc0e1c19667f0281 by Nate Graham. Committed on 03/08/2022 at 02:54. Pushed by ngraham into branch 'master'. Revert "Use onEntered in KickoffItemDelegate" This reverts commit 8042ae81d97cf27be1da652272d2dc86bfbbf042. This change slightly improved performance, but subtle implementation differences between the onEntered: and onPositionChanged: handlers in MouseArea triggered two subtle and annoying bugs that users have reported a bunch of duplicates of. A way to fix the bugs using onEntered has not been found, so let's revert the change for now; slightly worse performance is a less severe issue then these bugs are. Related: bug 454349 FIXED-IN: 5.25.5 M +6 -9 applets/kickoff/package/contents/ui/KickoffItemDelegate.qml M +0 -11 applets/kickoff/package/contents/ui/KickoffListView.qml https://invent.kde.org/plasma/plasma-desktop/commit/cfb520e3b39714edb6e9d406bc0e1c19667f0281
Git commit 3c87dc68746100960263ca35b400442170513474 by Nate Graham. Committed on 03/08/2022 at 03:14. Pushed by ngraham into branch 'Plasma/5.25'. Revert "Use onEntered in KickoffItemDelegate" This reverts commit 8042ae81d97cf27be1da652272d2dc86bfbbf042. This change slightly improved performance, but subtle implementation differences between the onEntered: and onPositionChanged: handlers in MouseArea triggered two subtle and annoying bugs that users have reported a bunch of duplicates of. A way to fix the bugs using onEntered has not been found, so let's revert the change for now; slightly worse performance is a less severe issue then these bugs are. Related: bug 454349, bug 456993 FIXED-IN: 5.25.5 (cherry picked from commit cfb520e3b39714edb6e9d406bc0e1c19667f0281) M +6 -9 applets/kickoff/package/contents/ui/KickoffItemDelegate.qml M +0 -11 applets/kickoff/package/contents/ui/KickoffListView.qml https://invent.kde.org/plasma/plasma-desktop/commit/3c87dc68746100960263ca35b400442170513474