Bug 472164

Summary:	KRunner should wait for results before starting the app
Product:	[Plasma] krunner	Reporter:	Saksham <saksham>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	REOPENED ---
Severity:	normal	CC:	alexander.lohnau, magunasu.b97, natalie_clarius, nate
Priority:	NOR
Version First Reported In:	5.27.5
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:	6.0
Sentry Crash Report:

Description Saksham 2023-07-11 19:25:42 UTC

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.

Comment 1 Nate Graham 2023-09-12 20:28:55 UTC

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!

Comment 2 Alexander Lohnau 2023-09-12 20:35:10 UTC

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 :)

Comment 3 Saksham 2023-09-13 01:48:37 UTC

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