Bug 455674

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

*** Bug 459371 has been marked as a duplicate of this bug. ***

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.

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.

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`

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

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

Hmm, then you have the change. Re-opening.

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?

Can it be that onPositionChanged got broken/changed with recent changes on qt5?

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

See also: https://bugs.kde.org/show_bug.cgi?id=454349#c17

(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.

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?

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.

(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.

For what it's worth, I cannot reproduce it neither on 5.25.5 nor on git master using openSUSE TW.

This (well, actually more accurately Bug 459371) was solved for me after upgrading to 5.26 and frameworks 5.99.

(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

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.

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?

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.