https://bugs.kde.org/show_bug.cgi?id=454349
--- Comment #41 from Noah Davis <noaha...@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
