STEPS TO REPRODUCE 1. Open Kicker 2. Type something OBSERVED RESULT There will be results and the second one will be highlighted, also if you press the arrow up key to select the first item it would sometimes move back to the second item on it own. EXPECTED RESULT The first one is highlighted SOFTWARE/OS VERSIONS Plasma 5.25 Beta, Arch Linux, Wayland
Cannot reproduce
I have experienced this on Arch with Plasma 5.24.90 beta. It seemed to go away after an update. Try updating with "sudo pacman -Syuu". I also disabled the "Desktop Search" application launcher plugin, so that may have fixed the issue.
Are you sure you're using Kicker and not Kickoff?
I did mean Kickoff , sorry.
Is it possible that the cursor is above the place where the second item appears?
(In reply to Nate Graham from comment #5) > Is it possible that the cursor is above the place where the second item > appears? No, my cursor is on the other side of the screen. Also, currently, it's not the second item it's the fifth. Does no one else have this issue?
Seems random-ish. I just managed to reproduce it, then I closed kickoff and tried again and it worked properly.
I can reproduce this consistently as well in kickoff, but I also seem to have figured out what happens (but not why). 1. Open kickoff and search for something 2. Highlight one of the options with the mouse 3. Press escape to close kickoff 4. Move the cursor away 5. Open kickoff and search for something again (it doesn't have to be the same term) When I do that, it selects the same entry that I hovered with the mouse in step 2. So if I hovered the third entry, it will select the third entry. It sometimes even reproduces without searching for anything once you re-open kickoff, if you had the cursor in a position where it would highlight something in the default view. If I search for something and hover the 6th entry on the left side of the view, once I re-open kickoff it selects "Games" without me doing anything. KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.12-arch1-1 (64-bit) Graphics Platform: Wayland
(In reply to Johan Sköld from comment #8) > 1. Open kickoff and search for something > 2. Highlight one of the options with the mouse > 3. Press escape to close kickoff > 4. Move the cursor away > 5. Open kickoff and search for something again (it doesn't have to be the > same term) > > When I do that, it selects the same entry that I hovered with the mouse in > step 2. So if I hovered the third entry, it will select the third entry. > Can reproduce on neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Graphics Platform: Wayland
I can reproduce that 100%!
*** Bug 456991 has been marked as a duplicate of this bug. ***
*** Bug 457092 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 455674 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 455674, 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 458569 has been marked as a duplicate of this bug. ***
Unfortunately this bug persists on Arch Linux running Plasma 5.26 beta and neon unstable. Sometimes I can reproduce with the steps from the comment 8. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Graphics Platform: Wayland
Hmm, I can't. Is there any chance the cursor is under any of the search results when it happens? If so, that would be Bug 455674.
(In reply to Nate Graham from comment #18) > Is there any chance the cursor is under any of the search > results when it happens? If so, that would be Bug 455674. No. My systems are affected by both this bug and bug 455674.
(In reply to Nate Graham from comment #18) > Hmm, I can't. I also cannot reproduce, neither on 5.25.5 nor on git master using openSUSE TW.
(In reply to postix from comment #20) > (In reply to Nate Graham from comment #18) > > Hmm, I can't. > I also cannot reproduce, neither on 5.25.5 nor on git master using openSUSE > TW. Never mind, I tested it again and I can confirm that the issue persists, but it's not always 100% reliably reproducible: 1. Open Kickoff 2. Click on one the icons in your favorite application's grid to open the application. For example one of the apps in the 2nd or 3rd row. 3. After the click move the mouse pointer away from Kickoff 4. Open Kickoff again by hitting "Meta" 5. Search for something, like "ka" (for kate) Result: Most of the time the selected search result were the item, which were at the position (height) of the clicked icon in step 3. Step 2 can be replaced by just hovering hover an icon, though it seemed to be easier to reproduce, when clicking on one. ;)
I can't reproduce that at all. :/
Clearly this bug is not fixed. I can reproduce easily with the steps from comment 8. Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: Wayland
I can confirm too on Arch Linux following the steps from comment 8. Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6800 XT
I still cannot reproduce the issue with those steps. Can anyone attach a screen recording?
(In reply to Nate Graham from comment #25) > I still cannot reproduce the issue with those steps. Can anyone attach a > screen recording? I can't reprocuce it as described comment 8, but I've seen this bug also on OpenSuse Tubleweed and Reborn OS (Arch)... I'm now doing some tests but I can't find a specific way to reproduce it 100% of the times :-/
(In reply to Nate Graham from comment #25) > I still cannot reproduce the issue with those steps. Can anyone attach a > screen recording? Sorry for the double post, but after some test I found a way to reproduce the bug. I can reproduce it using an italian word ("pro" the begin of "prova" that means "test"). 1) "Start" keyboard button > write "pro" > click on an application (e.g. Kate) 2) after Kate is opened 3) "Start" keyboard button > write "pro" > The selection is automatically moved to the previous mouse position If at the point 3) i search "test", the bug doesn't happen. I wanted to record it from X11, but on X11 the bug doesn't happen. Two questions: @Everyone is affected: are you using KDE in English or localized in your language? Maybe is a problem with localized Plasma @Nate: are you testing on Wayland? Unfortunately I haven't found anything more than this. Hope it can be somehow useful
I'm on Wayland with en_US locale, and I can't reproduce the issue by typing "pro" like that.
Created attachment 154704 [details] Screenshot: Fedora 37, Kat-e What works for me almost(!) always on Fedora 37 with Plasma 5.26.4: 1) E.g. 4x4 favourite grid 2) Kate at position (2,2), i.e. 2nd from left and top, so that it won't be on the height of the first line of the search result, but somewhere below 3) Click on Kate to open it. You can but not need to move the cursor away from where the Kickoff window is 4) Hit Meta or mouse click on the start menu and type "Kat", finally after a short pause add the "e". Now the search results change and the selection jumps to the position (height) where the Kate icon was before. I added a screenshot composition to this comment to make things a bit clearer. YMMV I'm afraid though.
I'd like to add, that once the bug was triggered, I can skip steps 1) to 3) and always reproduce it with the same search text(s). It may also happen with other input strings as in the example given above and it seems to be tied to search result updating, when entering single letters.
Created attachment 154705 [details] screen recording My system language is en-us and I can reproduce consistently with these steps: 1. Open kickoff and search for something 2. hover over a search result and move the mouse pointer vertically 3. Press ESC to close kickoff 4. Move the cursor away 5. Open kickoff and search for something again (it doesn't have to be the same term) Please watch the screen recording attached to this comment. Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: Wayland
Patrick Silva, can you confirm that it's not triggered in your screen recording, when you type "vid" only, but after you entered the "e", so that it becomes "vide" and the search results updates ? Thanks!
No. The bug occurs even if I type 'vid' when searching for the second time.
Aha. I can reproduce the issue consistently with these steps: 1. Open Kickoff with the Meta key 2. Search for "vid" 3. Use pointer to hover the fourth item 4. Close Kickoff with the Meta key 5. Move the pointer away 6. Open Kickoff with the Meta key again 7. Search for "vid" again Now the fourth item becomes inappropriately highlighted, even though the pointer is nowhere to be found. Let's see if I can fix it.
This is tricky. A key component of it seems to be that when this happens, the search field loses focus. I think there's some code somewhere that inappropriately forces focus to the view and triggers other code that isn't supposed to be run at that time.
Weird, can only reproduce on Wayland. On X this does not happen.
I'm on Wayland too, yeah. Is everyone affected using Wayland?
(In reply to Nate Graham from comment #37) > I'm on Wayland too, yeah. Is everyone affected using Wayland? yep, Wayland as well. Note, I cannot reproduce consistently - seems random in my case.
I'm on wayland, too
Thanks. I wonder if this is a Qt bug somewhere. Reducing priority from HI to NOR since we're not currently making Wayland-only bugs HI for the 15-minute bug initiative, only X11-only bugs or bugs affecting both platforms.
I managed to reproduce it once on wayland but that's all. I still don't know a way to reproduce it reliably. I haven't reproduced it on X11. To me, it seems very odd that this is a wayland specific issue. Knowing how Kickoff is written, I don't see any reason this should happen only on Wayland, unless the problem is elsewhere in the stack. Here's how it should work: 1. When kickoff is expanded (press Meta), the search field should be cleared. 2. When the search field is empty, replace the `searchView` with the `normalPage`. The `searchView` object should always be deleted when this is completed. 4. When a new search query is started, the `normalPage` should be replaced by a new `searchView` object, but `normalPage` is never unloaded. Since this is a new `searchView` object, it should be using the default value for `currentIndex`, which is `count > 0 ? 0 : -1` in `KickoffListView.qml`. My first thought was that this could be some kind of timing issue where the search view is not deleted fast enough before being used again, but I was not able to reproduce the issue while loading Plasmashell in GammaRay (which frequently closes itself, making it useless anyway). Thinking about it further, that shouldn't be the reason anyway since the current index should be reset to 0 whenever kickoff is expanded. It also didn't go back to the last hovered index until the exact same search query was used when I managed to reproduce it. Another thought is that it could be a problem with `reuseItems: true`. Maybe there's some magic keeping a previously hovered delegate item alive, the delegate is reused and the delegate thinks it's still hovered, somehow setting the current index to the delegate's index. That still seems unlikely because of other previously mentioned ways of resetting the current index or unloading the search view.
Thanks for looking anyway. This is one bizarre bug.
*** Bug 464855 has been marked as a duplicate of this bug. ***
Found it - partly Qt has a codepath where if a mousearea moves so that it now enters the last known position of the mouse we send a hover event into that item. This generally is a good thing. This is in the path QQuickWindowPrivate::flushFrameSyncronousEvents (which is making it a max of once per frame) Our lastMousePosition is not reset when we close the window. This normally gets reset in QEvent::Leave which happens if we mouse out, but not when we close a window. We can either make QtDeclarative clean up on window close too, or make QtWayland send a synthetic mouse leave event on window close. I'm not sure which is the most-right. It could be hacked plasma-side, but we may as well patch Qt and do it properly.
This should fix it: https://codereview.qt-project.org/c/qt/qtdeclarative/+/457096 Then we'll need to backport a modified version into our patch collection as qquickdeliveryagent didn't exist there.
Other plasmoids are also affected by this, e.g. notification history. STEPS TO REPRODUCE 1. Open notification history (make sure there is at least 1 notification present) 2. Clear notification history 3. Wait for or provoke another notification to be added to the history 4. Open notification history again OBSERVED RESULT "Clear notification history" button is hovered until the mouse enters the plasmoid EXPECTED RESULT "Clear notification history" button is not hovered
(In reply to Naxdy from comment #46) > Other plasmoids are also affected by this, e.g. notification history. > > STEPS TO REPRODUCE > 1. Open notification history (make sure there is at least 1 notification > present) > 2. Clear notification history > 3. Wait for or provoke another notification to be added to the history > 4. Open notification history again > > OBSERVED RESULT > "Clear notification history" button is hovered until the mouse enters the > plasmoid > > EXPECTED RESULT > "Clear notification history" button is not hovered I can reproduce this on Arch Linux plasma 5.27.1 using these exact steps
(In reply to Naxdy from comment #46) > Other plasmoids are also affected by this, e.g. notification history. > > STEPS TO REPRODUCE > 1. Open notification history (make sure there is at least 1 notification > present) > 2. Clear notification history > 3. Wait for or provoke another notification to be added to the history > 4. Open notification history again > > OBSERVED RESULT > "Clear notification history" button is hovered until the mouse enters the > plasmoid > > EXPECTED RESULT > "Clear notification history" button is not hovered Possibly it's a different bug. See bug 345852
This should be fixed in Plasma 6.0, due to a pending Qt change that fixes the root cause issue in Qt itself: https://codereview.qt-project.org/c/qt/qtdeclarative/+/457096.
(In reply to Nate Graham from comment #49) > This should be fixed in Plasma 6.0, due to a pending Qt change that fixes > the root cause issue in Qt itself: > https://codereview.qt-project.org/c/qt/qtdeclarative/+/457096. o/ Can this be backported to the Qt5 KDE patch collection?
Perhaps. I'd say it's up to David.
*** Bug 467304 has been marked as a duplicate of this bug. ***
*** Bug 467765 has been marked as a duplicate of this bug. ***
*** Bug 468502 has been marked as a duplicate of this bug. ***