SUMMARY When using the search function in the task manager or when using KRunner, I open type quite fast and hit enter as soon as I am done typing (and expect the correct result to show up) even if the search is not fully complete. This often results in the wrong application from starting. replicating this exactly is a little difficult because the timing is relatively precise. STEPS TO REPRODUCE 1. open task bar search 2. immediately type "fire" (searching for firefox) 3. *immediately* hit enter OBSERVED RESULT The files app opens. You will notice that when you type "fi", the files app is listed at the top above firefox. when you finish typing "fire", files will still be at the top for a small amount of time before firefox becomes the top result (waiting for search to complete). if you press enter before firefox is at the top, the files app will open even if the user clearly intended firefox to launch. this also happens with other applications but this is the one I found to happen most often. EXPECTED RESULT firefox opens instead of files. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 38 (nobara official with x11) Specs: i7-8750h + gtx1060 ADDITIONAL INFORMATION This could be fixed by changing krunner so typing a letter will immediately invalidate all results until the search is complete with the new character. Then open the result even if the search is complete after the user presses the enter button. TLDR: close krunner/taskbar after user presses enter, complete search in the background, open top result I hope my explanation makes sense.
This has been substantially improved for Plasma 6. Let's call it fixed for now, but feel free to re-open the bug report if after upgrading to Plasma 6, you find that it's not improved enough for your satisfaction. Thanks!
The principle is still valid though. Even if the optimizations improved performance (there are a handful more patches coming that have an even greater effect), a slow runner but with highly relevant matches (and thus at the top) could still cause users to accidentally open the wrong result. IIRC there was a related bug report, will check in more detail when I find time :)
(In reply to Nate Graham from comment #1) > This has been substantially improved for Plasma 6. Let's call it fixed for > now, but feel free to re-open the bug report if after upgrading to Plasma 6, > you find that it's not improved enough for your satisfaction. Thanks! In my opinion, it is still a pseudo "race" condition. even if the timing window is significantly reduced, that problem still persists.