Bug 455674

Summary: Unmoving cursor continually reselects the menu item it's hovering over
Product: [Plasma] plasmashell Reporter: Phil Hord <phil.hord>
Component: Application Launcher (Kickoff)Assignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: abhijeetviswa, agrinev98, bugseforuns, eric1, jmowery, markovs.i.mail, me, mikel5764, miranda, nate, noahadvs, notmart, orangewinds, postix
Priority: HI Keywords: regression, usability
Version: 5.26.2   
Target Milestone: 1.0   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In: 5.25.5
Attachments: Video demo where I press only Meta, Down, Down, Down, Down
Settings icon is focused without cursor

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
Comment 18 Nate Graham 2022-09-22 19:42:10 UTC
*** Bug 459371 has been marked as a duplicate of this bug. ***
Comment 19 Iyán Méndez Veiga 2022-09-22 20:09:46 UTC
I would like to reopen this because I don't think it's fixed. At least, not completely. I will be happy to make some videos to show my issue, but first I will try to write the steps to reproduce, so hopefully someone else can reproduce and reopen.

STEPS TO REPRODUCE
1. Place the mouse over some area where kickoff normally opens
2. Press meta to open kickoff
3. Type Firefox (or any other app with potential many results)

OBSERVED RESULT
Results are correctly ordered. Firefox is the first entry, followed by Tor Browser and Mozilla VPN entries, and then some URLs. Without touching the mouse, touchpad or the screen, the selected entry goes directly to where the mouse is pointing instead of staying in the first entry of the results. Sometimes I was able to make it stay in the first entry if I type quickly, but it feels quite random to be honest. I can replicate both in X11 and Wayland.

EXPECTED RESULT
(Exactly what original bug reports says) Keyboard selection should override mouse cursor selection until I move the mouse again.
Comment 20 Iyán Méndez Veiga 2022-09-22 21:01:49 UTC
https://drive.switch.ch/index.php/s/QphpbL0SHLcwo5t

Okay, so here is the video, just in case. Note that the behavior also depends on what I type. When I write "Element", it works as expected. When I write "Firefox", no. This was recorded using X11, but exactly same happen in Wayland.
Comment 21 Nate Graham 2022-09-23 19:17:01 UTC
I'm extremely confused by how you're getting that to happen, because your video is showing the exact behavior we fixed here, which I could reproduce 100% before the fix, and not cannot reproduce at all. It's like you don't actually have the fix applied or something.

What distro and version of Plasma are you using?

What is the output of `grep -i onEntered /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffItemDelegate.qml`
Comment 22 Iyán Méndez Veiga 2022-09-23 20:09:14 UTC
So Arch Linux, I paste from my desktop with X11. But same thing happen on my laptop with Wayland.

Operating System: Arch Linux
KDE Plasma Version: 5.25.90
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.10-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: Z97P-D3

And I don't have exact file on my system, but I do have AbstractKickoffItemDelegate.qml.

$ grep -i onEntered /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/AbstractKickoffItemDelegate.qml
        // Using onPositionChanged instead of onEntered because it enables several
Comment 23 Iyán Méndez Veiga 2022-09-23 20:12:56 UTC
This file is owned by package plasma-desktop, which is build directly from source without any additional patches.

$ pacman -Qo /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/AbstractKickoffItemDelegate.qml
/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/AbstractKickoffItemDelegate.qml is owned by plasma-desktop 5.25.90-1

https://github.com/archlinux/svntogit-packages/commit/f4bbf8d5d4a8ea81e7c043c22981ef2373ecbc68
Comment 24 Nate Graham 2022-09-26 21:40:17 UTC
Hmm, then you have the change. Re-opening.
Comment 25 Nate Graham 2022-09-26 21:40:43 UTC
I'm at a loss to explain how this issue could possibly still be happening for you.

Can anyone else using the beta reproduce it?
Comment 26 Iyán Méndez Veiga 2022-09-26 23:09:38 UTC
Can it be that onPositionChanged got broken/changed with recent changes on qt5?
Comment 27 Iyán Méndez Veiga 2022-09-26 23:12:07 UTC
These are the versions I have:

$ pacman -Q | grep qt5-quick       
qt5-quick3d 5.15.6+kde+r1-1
qt5-quickcontrols 5.15.6+kde+r0-1
qt5-quickcontrols2 5.15.6+kde+r5-1
Comment 28 Iyán Méndez Veiga 2022-09-27 10:34:03 UTC
See also: https://bugs.kde.org/show_bug.cgi?id=454349#c17
Comment 29 Patrick Silva 2022-09-27 10:45:18 UTC
(In reply to Nate Graham from comment #25)
> Can anyone else using the beta reproduce it?
Sometimes the bug occurs on my Arch Linux running Plasma 5.26 beta. I can't reproduce consistently.
Neon unstable is also affected.
Comment 30 Nate Graham 2022-09-28 02:56:02 UTC
And just like that, I can reproduce it today. :(

What's weird is that it seems to be based on the exact position of the cursor within the applet's popup: if I position the cursor such that it will be under the second search result once the results list appears, the bug doesn't happen. But if I position the cursor so that it's close to the bottom of the popup and it would select the 8th or 9th entry when the results list appears, it happens every time.

Can you reproduce that?
Comment 31 Iyán Méndez Veiga 2022-09-28 06:58:28 UTC
Can it also be depending on what type of results are shown? I disabled most of the search plugins in Search -> Plasma Shell, and this bug seems to go away.
Comment 32 Iyán Méndez Veiga 2022-09-28 06:59:54 UTC
(In reply to Nate Graham from comment #30)
> And just like that, I can reproduce it today. :(
> 
> What's weird is that it seems to be based on the exact position of the
> cursor within the applet's popup: if I position the cursor such that it will
> be under the second search result once the results list appears, the bug
> doesn't happen. But if I position the cursor so that it's close to the
> bottom of the popup and it would select the 8th or 9th entry when the
> results list appears, it happens every time.
> 
> Can you reproduce that?

Okay, even with most search plugins disabled, I can reproduce this.
Comment 33 postix 2022-09-28 11:22:42 UTC
For what it's worth, I cannot reproduce it neither on 5.25.5 nor on git master using openSUSE TW.
Comment 34 Iyán Méndez Veiga 2022-10-13 10:45:29 UTC
This (well, actually more accurately Bug 459371) was solved for me after upgrading to 5.26 and frameworks 5.99.
Comment 35 Patrick Silva 2022-10-13 12:08:51 UTC
(In reply to Iyán Méndez Veiga from comment #34)
> This (well, actually more accurately Bug 459371) was solved for me after
> upgrading to 5.26 and frameworks 5.99.

Bug 459371 is still reproducible on my Arch, but not consistently.

Operating System: Arch Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Graphics Platform: Wayland
Comment 36 Iyán Méndez Veiga 2022-10-13 16:47:12 UTC
Okay, after trying a bit more, I can still find some particular times where the selection moves. And I can always reproduce those events. But it's like it depends on the particular search I do or the output of the search. Weird. For example, before I could reproduce always when typing "firefox". Now this works as intended. But if I write "telegram", selection moves to where the mouse is.
Comment 37 Marco Martin 2022-11-04 12:43:21 UTC
can't seem to reproduce..
sometimes dirty sensors in mice/shaky touch sensors can cause the cursor to shake a little bit, even just one pixel every now and then... 
are we sure this can be exclude?
Comment 38 Nate Graham 2022-11-04 13:41:04 UTC
It's no longer exactly as described in the title... As this issue is now fixed, I'll re-open the duplicate report Bug 456231 which describes the actual issue, which is very strange.