Bug 455674 - Unmoving cursor continually reselects the menu item it's hovering over
Summary: Unmoving cursor continually reselects the menu item it's hovering over
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Unclassified
Component: Application Launcher (Kickoff) (show other bugs)
Version: 5.25.0
Platform: Neon Packages Linux
: HI normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: regression, usability
: 455724 455972 456231 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-06-20 20:05 UTC by Phil Hord
Modified: 2022-08-03 03:14 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25.5


Attachments
Video demo where I press only Meta, Down, Down, Down, Down (689.05 KB, image/gif)
2022-06-20 20:05 UTC, Phil Hord
Details
Settings icon is focused without cursor (184.66 KB, image/png)
2022-06-29 19:01 UTC, Komorebi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Hord 2022-06-20 20:05:32 UTC
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 1 Phil Hord 2022-06-20 20:07:03 UTC
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.
Comment 2 Noah Davis 2022-06-20 21:33:25 UTC
Is this a new problem or has the problem been around for a few releases?
Comment 3 Phil Hord 2022-06-21 02:09:56 UTC
(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.
Comment 4 Noah Davis 2022-06-21 15:29:35 UTC
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.
Comment 5 Nate Graham 2022-06-21 18:27:58 UTC
We fixed this ages ago in the old Kickoff, then IIRC again in the new one, and I guess it's broken again.
Comment 6 Nate Graham 2022-06-21 18:31:42 UTC
*** Bug 455724 has been marked as a duplicate of this bug. ***
Comment 7 Artem Grinev 2022-06-21 20:48:36 UTC
(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.
Comment 8 Noah Davis 2022-06-21 21:27:45 UTC
(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.
Comment 9 Komorebi 2022-06-26 14:54:54 UTC
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
Comment 10 Noah Davis 2022-06-26 19:33:10 UTC
*** Bug 455972 has been marked as a duplicate of this bug. ***
Comment 11 Noah Davis 2022-06-26 19:40:40 UTC
(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.
Comment 12 Komorebi 2022-06-26 20:15:27 UTC
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.
Comment 13 Komorebi 2022-06-29 19:01:27 UTC
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?
Comment 14 Nate Graham 2022-07-05 16:38:55 UTC
*** Bug 456231 has been marked as a duplicate of this bug. ***
Comment 15 Bug Janitor Service 2022-08-02 22:47:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1074
Comment 16 Nate Graham 2022-08-03 02:55:31 UTC
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
Comment 17 Nate Graham 2022-08-03 03:14:59 UTC
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