Bug 442987

Not sure there is a bug here. It always runs the top item. The top item can change as you add more characters; that's how you refine your search term to get closer to the thing you want to launch.

Does the same thing happen in KRunner?

Haven't tested in krunner yet.

The thing is, the list of items takes some time to update upon every edit in the input box (and I think the list sometimes changes multiple times for one key press). If the user presses Enter faster than the launcher updates the list, then the top item may be for an outdated query or even the query results may not represent the final item list for any given query.

Suggested fix: when Enter is pressed, the launcher should wait for any ongoing search queries to finish.

Are you using a very slow computer? The list updates practically instantly for me. Regardless, making it wait for the query to complete would probably be really frustrating for users of slow computers in particular.

Re: comment #4

I tested this on a 5 year old gaming laptop (i7, 16 GiB - no constant swapping, a spinning HDD). The spinning HDD can explain th slowness in a cold test. However I can also reproduce another time again and again when icons and stuff must already be cached; this makes me think of
 1. CPU-bound slowness of QML
 2. Debouncing (not sure if it's there) that may delay searching.

Considering professional SC2 players don't normally exceed 1500 APM, we can assume most users won't press/release keys with an interval shorter than 40 ms, BUT...

If you're connecting over remote desktop, I can imagine network latency jitter or packet loss may randomly reduce this interval even further.

So is the problem here that the selected item in the search results list changes rapidly, or that an item is launched which isn't the selected item?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

> So is the problem here that the selected item in the search results list changes rapidly, or

No, this is not a problem in itself. It's more like "the selected item in the search results doesn't change rapidly enough to keep up with user input".

> that an item is launched which isn't the selected item?

No. I believe the selected item is launched.

I encounter the same issue on a fairly decent NVMe SSD (gigabytes per second sequential read). When I type "ok", Okular is highlighted as the first result, with Okteta as the second result. If I type "t", it takes around 1/4 of a second for Okular to disappear from the list. If I press Enter too quickly, Okular opens despite not matching the "okt" search query.

Oddly the initial "O" keystroke is quite fast to respond, "k" is nearly instant, but "t" is a lot slower for the search results to update. This persists after restarting plasmashell.

Operating System: Arch Linux
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.11-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2

Same problem here, this is incredibly frustrating. This "seems" to occur much more frequently with 5.24 (noticed it 1-2 months ago? maybe more).

I have a AMD 5950X CPU and a PCIE 4.0 SSD, slowness of my system really shouldn't be an issue. I wouldn't call myself a fast typer, but of course for frequent tasks, I have developed quite a muscle memory, so in KRunner, I type fast. Either way, this HAS TO BE (relatively) easily programatically solveable by simply making sure that when enter is pressed, the default entry corresponding to the latest input preceding enter is loaded/selected first...

This is present in 5.25/5.95 as well. It would seem that if you have many Plasma Search plugins enabled it exacerbates the problem. IMHO there just needs to be a check when the enter key is pressed to wait until the list has finished updating (and possibly not accept any further input). This will slow down the interaction and not allow applications to launch instantly on the 'enter' keypress but it will solve the issue of incorrect entries being selected for very fast typists.

Noticed this bug too, pretty frustrating. I have an app that has 'Chat' in its name. I also have Telegram Desktop installed that has 'Chat' in its categories. When I quickly type 'chat' and press Enter - Telegram opens, but if I wait just a bit, the other chat app jumps up and Enter selects it. Also, don't remember this happening before 5.25.

(In reply to Nate Graham from comment #4)
> Are you using a very slow computer? The list updates practically instantly
> for me. Regardless, making it wait for the query to complete would probably
> be really frustrating for users of slow computers in particular.

This does not seem like a relevant argument, typically a user will only type in the neccesarry amount of characters to distinguish applications on their system. Using the first comment as an example, when differentiating between Okteta and Okular, the user will likely only type "oct" however this collides with a builtin math function so "octe". Arguing waiting for a check would be bad for slow computer users is irrelevant because they must still wait for the list to finish its repopulation anyway to receive the correct result before pressing the enter key. In effect, they will benefit because they can type in the term that they know will launch the correct application and smash enter and let their eyes glaze over while wating for the application to load.

> IMHO there just needs to be a check when the enter key is pressed to wait until the list has finished updating

That seems reasonable, though I'd add a max timeout of maybe 500 ms too, since runners might take a while in case they do network requests or sth. like that.

>Oddly the initial "O" keystroke is quite fast to respond, "k" is nearly instant, but "t" is a lot slower for the search results to update.

This is to a certain degree expected, because often runners require at least 3 character to be typed before they produce any results. Exceptions are for example the Application, Systemsettings, or File Search runners.

Disabling file search seems to have mitigated the issue for me. The size of baloo index is ~2GB (with content indexing disabled) - is that normal?

(In reply to Alexander Popel from comment #17)
> Disabling file search seems to have mitigated the issue for me. The size of
> baloo index is ~2GB (with content indexing disabled) - is that normal?

I have file search disabled and I still can run into the issue. Though it would be nice to still be able to use file search when baloo doesn't crash.