Bug 416145 - Krunner doesn't immediately intercept rapidly-typed keystrokes for first invocation after login, leading the user to accidentally type text into whatever app is open
Summary: Krunner doesn't immediately intercept rapidly-typed keystrokes for first invo...
Status: CONFIRMED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.22.3
Platform: Kubuntu Linux
: NOR normal with 40 votes (vote)
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 374660 377054 401696 413420 416776 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-01-12 01:46 UTC by leftcrane
Modified: 2022-11-19 04:58 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-4364-0.html (788 bytes, text/html)
2020-06-14 01:38 UTC, Doug
Details
attachment-23671-0.html (1017 bytes, text/html)
2020-06-29 23:44 UTC, Doug
Details
attachment-24621-0.html (1.37 KB, text/html)
2020-07-03 05:46 UTC, Doug
Details

Note You need to log in before you can comment on or make changes to this bug.
Description leftcrane 2020-01-12 01:46:02 UTC
SUMMARY


STEPS TO REPRODUCE
1. Open a text editor
2. Invoke Krunner
3. IMMEDIATELY start typing, don't wait for the dialog to pop up.

OBSERVED RESULT

Half of your text will be entered into the text editor, and the other half will be entered into Krunner. Krunner isn't terribly fast to open (about 0.3 sec delay on my machine), and until the dialog pops, it's not intercepting your keystrokes.

This is unacceptable behavior for a launcher IMO. It never happens on Gnome or Windows AFAIK.

EXPECTED RESULT

The launcher should start intercepting all keystrokes entered after invoking the launcher, even if it can't draw the actual input dialog fast enough. Of course it's important to display the popup quickly - and KRunner could definitely use a performance improvement - but it is doubly important for a slow launcher to start capturing right away because otherwise the user will end up typing text into whatever window is open. This happens to me regularly when using krunner.
Comment 1 Nate Graham 2020-01-12 23:50:26 UTC
Yeah, can confirm.
Comment 2 Doug 2020-01-14 03:56:41 UTC
If I invoke krunner by typing on the desktop it won't accept the first letter typed the first time it is invoked- but other letters will come through even when they were typed before the input dialogue box appears.  For example, if I type "shut down" really fast before the box pops up it will appear as "hut down".

When krunner is invoked again during the same session it will work correctly.

This is in KDE Neon 5.17.5
Comment 3 phd 2020-01-16 21:07:21 UTC
Since this issue was annoying me for some time now,
I have just submitted a pull request to fix it (and one more):
https://phabricator.kde.org/D26718

@Kai Uwe Broulik
I haven't noticed this bug report earlier, and now I see you are assigned to it.
Do you have a different solution already? Would you mind checking mine? Thanks.
Comment 4 Nate Graham 2020-01-28 19:08:58 UTC
*** Bug 416776 has been marked as a duplicate of this bug. ***
Comment 5 phd 2020-03-02 20:23:15 UTC
https://phabricator.kde.org/D26718 was modified to resolve this issue for DesktopView only.

@leftcrane
For running KRunner from shortcut: you may workaround this by autostarting the KRunner service:
`krunner --daemon`
Comment 6 David Edmundson 2020-03-27 16:26:44 UTC
*** Bug 413420 has been marked as a duplicate of this bug. ***
Comment 7 David Edmundson 2020-03-27 16:29:15 UTC
There are some other steps we can do.

To get input we just need a window with focus. We don't need it loaded with the QML.

We can swap this to be

 - create window
 - show() (but invisible and empty)
 - load QML (and libplasma and all the heavy parts)
 - show and position

input won't get dispatched till the event loop runs, at which point we'll have our text field.
Comment 8 David Edmundson 2020-04-03 11:33:29 UTC
Git commit 1c48e351c646212c539392a361a93606274b9211 by David Edmundson.
Committed on 03/04/2020 at 11:32.
Pushed by davidedmundson into branch 'master'.

[krunner] Avoid reparsing the config load on start

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: apol, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28365

M  +10   -5    krunner/view.cpp
M  +1    -1    krunner/view.h

https://commits.kde.org/plasma-workspace/1c48e351c646212c539392a361a93606274b9211
Comment 9 David Edmundson 2020-04-03 11:33:29 UTC
Git commit 6dc04ef0adec2e96f81766d5d2b5b2483f1ad145 by David Edmundson.
Committed on 03/04/2020 at 11:33.
Pushed by davidedmundson into branch 'master'.

[krunner] Avoid a uneeded pointless config parse

Summary:
We are krunner, our default config will be krunnerrc, we can load the
instance we've already loaded in the QPT instead of doing it again.

Reviewers: #plasma, apol, broulik

Reviewed By: #plasma, apol, broulik

Subscribers: apol, plasma-devel
Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28368

M  +1    -1    krunner/view.cpp

https://commits.kde.org/plasma-workspace/6dc04ef0adec2e96f81766d5d2b5b2483f1ad145
Comment 10 David Edmundson 2020-04-03 11:33:29 UTC
Git commit e2d372d3dfd14ea3210a9e1f5755883bd2578c18 by David Edmundson.
Committed on 03/04/2020 at 11:32.
Pushed by davidedmundson into branch 'master'.

[krunner] Don't set the position three times in a row

Summary:
loadConfig calls setFreeFloating. setFreeFloating calls
setLocation

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: pereira.alex, ngraham, broulik, plasma-devel
Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28366

M  +0    -7    krunner/view.cpp

https://commits.kde.org/plasma-workspace/e2d372d3dfd14ea3210a9e1f5755883bd2578c18
Comment 11 ariasuni 2020-05-03 02:06:02 UTC
Hi, I still have this issue in Plasma 5.18.4.1. I’m not sure I’m running a version with the improvements of David Edmundson, though.

I think that this issue is important because it can give the impression that Plasma is slow or buggy.

Regularly, *even when KRunner is already started*, the first letter I type after using the keyboard shortcut is entered in the wrong place (aka in my browser or my code editor), on a powerful laptop.

It’s very annoying because I may not have noticed I typed a letter in the wrong place, thinking the letter was just «lost», because when invoking Krunner I’m already thinking of the next task and I don’t remember where my cursor/focus was.

So starting KRunner ahead of time is not a working workaround for me, because my issue is the time an already opened Krunner take to capture input.
Comment 12 ariasuni 2020-05-10 02:23:35 UTC
Disabling the unit converter fixes the problem for me, so maybe this is an issue with some runners.

I’m not sure if the issue is from kdeplasma-addons (where there’s krunner_converter) or from frameworks-kunitconversion, though.
Comment 13 Nate Graham 2020-05-12 15:59:48 UTC
Hmm, the unit converter runner shouldn't be that heavy. If you really want to improve this, disable the "Software Center" runner.
Comment 14 ariasuni 2020-05-12 22:38:11 UTC
I don’t use the “Software Center” runner. Interestingly, I don’t see a difference between enabling it or not today, though at the time of the test my system was under more load than right now.

Anyway, it’s not fixed for me after all, there is still delay even when disabling all the runners.
Comment 15 Alexander Lohnau 2020-06-12 19:30:53 UTC
Is this still an issue? For me it works properly on On KDE Neon unstable.
Comment 16 Nate Graham 2020-06-13 00:48:20 UTC
Still an issue for me.
Comment 17 Doug 2020-06-14 01:38:25 UTC
Created attachment 129332 [details]
attachment-4364-0.html

I'm still having this issue as well.

On Fri, Jun 12, 2020 at 8:48 PM Nate Graham <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=416145
>
> --- Comment #16 from Nate Graham <nate@kde.org> ---
> Still an issue for me.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 18 Alexander Lohnau 2020-06-29 19:03:36 UTC
Could you please check if it got fixed/improved by https://invent.kde.org/ngraham/plasma-workspace?

@ngraham already reported that this seems to improve the issue.
Comment 20 Alexander Lohnau 2020-06-29 19:34:08 UTC
Whoops
Comment 21 Doug 2020-06-29 23:44:26 UTC
Created attachment 129779 [details]
attachment-23671-0.html

I'm sorry, I am guessing this is a patch you want me to apply?  I am not a
developer, and do not know how to do this.  If it's something you can walk
me through without taking too much of your time, I'm game- but I'd
understand if not.

On Mon, Jun 29, 2020 at 3:34 PM Alexander Lohnau <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=416145
>
> --- Comment #20 from Alexander Lohnau <alexander.lohnau@gmx.de> ---
> Whoops
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 22 Nate Graham 2020-06-30 04:47:55 UTC
If you don't want to cmopile krunner from source (for that, see https://community.kde.org/Get_Involved/development#Plasma) you could maybe install KDE Neon Unstable edition in a VM after a few days and test in there.
Comment 23 Doug 2020-07-03 05:46:06 UTC
Created attachment 129859 [details]
attachment-24621-0.html

I've installed KDE Neon Developer's Edition in a VM.  After updating and
restarting, krunner crashes immediately upon trying to invoke it by typing
on the desktop.  I can submit the crash report and backtrace this weekend
sometime, but I just wanted to let you guys know I'm still here!

Doug

On Tue, Jun 30, 2020 at 12:47 AM Nate Graham <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=416145
>
> --- Comment #22 from Nate Graham <nate@kde.org> ---
> If you don't want to cmopile krunner from source (for that, see
> https://community.kde.org/Get_Involved/development#Plasma) you could maybe
> install KDE Neon Unstable edition in a VM after a few days and test in
> there.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 24 Doug 2020-07-09 21:50:55 UTC
I've disabled the PIM Contact Search module that was causing krunner to crash per Bug 423003, but the behavior of krunner seems the same as before.  I'm on Neon Developer's Edition 5.19.80, updated as of 7/9/20.

Just to be clear, when I have focus on the desktop and krunner has not been started, is the desired behavior of krunner:

A) typing "Hello" should invoke krunner and send "Hello" to the text box

or 

B) typing "Hello" should invoke krunner, and send "ello" to the text box

I'm getting A, but if it's supposed to be B then I guess it is working, though it would seem a papercut if not a bug.
Comment 25 Nate Graham 2020-07-09 22:27:53 UTC
It's supposed to be A, so I'm happy to hear that it's working. :)
Comment 26 Doug 2020-07-09 22:59:51 UTC
Sorry, I meant to say I'm getting "B"- stupid typo on my part!  But I went back to check on this again, and found that it's a bit more complicated.  If I type "Hello" quickly, or at least normal speed, I get "ello".  If I type "H" and wait for the text box to appear, it will appear with an "H" in it, after which I can add the "ello".  I checked this several times, stopping "krunner" between each attempt, and it is consistent.
Comment 27 Patrick Silva 2020-07-09 23:29:59 UTC
This issue persists on my neon unstable too.
The first character typed when desktop is focused and krunner isn't running in background doesn't appear in the search field.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.72.0
Qt Version: 5.14.2
Comment 28 Nate Graham 2020-07-09 23:48:39 UTC
Darn.
Comment 29 Alexander Lohnau 2020-07-10 05:57:59 UTC
It seems like we are mixing two cases here:

1) KRunner is invoked by Alt+Space and we immediately start typing
2) We are on the Desktop and type really fast (don't wait for KRunner to show up or invoke it manually).
Comment 30 phd 2020-07-10 07:31:22 UTC
There is a patch ready for using KRunner from the Desktop View:
https://phabricator.kde.org/D26718

As for Alt+Space/Alt+F2, there is no solution so far
other than autostarting KRunner in advance.

But maybe for this shortcut we could:
1. run KRunner
2. focus Plasma Destktop View
and rely on the solution above?
Comment 31 phd 2020-07-10 07:44:27 UTC
>https://phabricator.kde.org/D26718
I guess I should submit this to GitLab now, right?
Comment 32 Alexander Lohnau 2020-07-10 09:13:03 UTC
Yes please :-)
Comment 33 phd 2020-07-10 10:26:00 UTC
>>https://phabricator.kde.org/D26718
>I guess I should submit this to GitLab now, right?
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/148
Comment 34 Patrick Silva 2020-07-10 11:01:35 UTC
(In reply to Alexander Lohnau from comment #29)
> It seems like we are mixing two cases here:
> 
> 1) KRunner is invoked by Alt+Space and we immediately start typing
> 2) We are on the Desktop and type really fast (don't wait for KRunner to
> show up or invoke it manually).

Case 1 is also reroducible on neon unstable.
Comment 35 Alexander Lohnau 2020-07-10 12:09:29 UTC
(In reply to Patrick Silva from comment #34)
> Case 1 is also reroducible on neon unstable.
Weird, I don't have any of these issues on one of my setups. And the other (very recent KDE Neon Unstable install with latest updates) I only have Case2, Case1 was fixed for me with the latest change.
Comment 36 Alexander Lohnau 2020-07-11 14:43:31 UTC
*** Bug 377054 has been marked as a duplicate of this bug. ***
Comment 37 Alexander Lohnau 2020-07-11 14:54:29 UTC
*** Bug 374660 has been marked as a duplicate of this bug. ***
Comment 38 Alexander Lohnau 2020-07-11 15:29:49 UTC
*** Bug 401696 has been marked as a duplicate of this bug. ***
Comment 39 Alexander Lohnau 2020-08-23 18:41:05 UTC
On related not when discussing the issue on reddit people reported that using the KRunner plasmoid called "Search" works really good as a workaround.

Maybe someone finds this useful :)
Comment 40 Nate Graham 2020-09-09 18:55:26 UTC
Git commit 003e30a64e976e66c02d3aa8b06301710a231889 by Nate Graham, on behalf of Piotr Henryk Dabrowski.
Committed on 09/09/2020 at 18:54.
Pushed by ngraham into branch 'master'.

aggregate text for KRunner in DesktopView

Aggregate text for KRunner in DesktopView to prevent eating fast-typed characters.
partial solution: resolved for DesktopView, not resolved for running KRunner from shortcut

Test Plan:
When DesktopView is focused, typed characters show KRunner query.
All fast-typed characters should now appear correctly in KRunner window,
instead of only first typed character.

M  +35   -12   shell/desktopview.cpp
M  +2    -0    shell/desktopview.h

https://invent.kde.org/plasma/plasma-workspace/commit/003e30a64e976e66c02d3aa8b06301710a231889
Comment 41 David Redondo 2020-09-11 12:23:53 UTC
Git commit 0e575a20ef36532b5b40a40ea30f915976942477 by David Redondo.
Committed on 11/09/2020 at 12:23.
Pushed by davidre into branch 'master'.

Activate KRunner instead of running the binary

Currently when we invoke KRunner and it is already running we will start binary,
KDBusService will check if it is already registered and then call
org.freedesktop.Application.Activate. Cutting the middle out should improve the
time that it takes to show KRunner and make it less likely that key strokes are
lost. If KRunner is not running we, can rely on dbus activiation to start KRunner.
Unfortunately we cannnot call Activate with dbus-send because it doesn't support
it's argument type. Instead we can just use the existing display method.

M  +1    -2    krunner/CMakeLists.txt
R  +2    -2    krunner/krunner.desktop [from: krunner/krunner.desktop.cmake - 094% similarity]

https://invent.kde.org/plasma/plasma-workspace/commit/0e575a20ef36532b5b40a40ea30f915976942477
Comment 42 ariasuni 2020-09-15 12:44:34 UTC
With the above commit, it’s very very hard to miss more than one letter. I easily miss the first letter though, so it’s not a definitive fix.
Comment 43 phd 2020-09-15 13:02:10 UTC
Can the Alt+F2 shortcut do two things:
1. immediately focus the desktop (so that we can relay on [1] from here)
2. then show/execute KRunner (with the above in place it doesn't need to be that fast)?

[1] "aggregate text for KRunner in DesktopView"
https://invent.kde.org/plasma/plasma-workspace/commit/003e30a64e976e66c02d3aa8b06301710a231889

@ariasuni
You mean the Alt+F2 invocation, not the desktop typing?
Comment 44 ariasuni 2020-09-16 21:27:22 UTC
Yes, I was talking about the situation where I invoke KRunner with Alt-F2.
Comment 45 phd 2020-09-17 19:45:43 UTC
> Can the Alt+F2 shortcut do two things:
> 1. immediately focus the desktop (so that we can relay on [1] from here)
> 2. then show/execute KRunner (with the above in place it doesn't need to be that fast)?

Probably we could do that like this:

Alt+F2 calls this new PlasmaShell's method:

dbus-send --type=method_call --dest=org.kde.plasmashell /PlasmaShell org.kde.plasmashell.PlasmaShell.displayKRunner

which does two things:

1. immediately focuses the desktop

2. then calls (using Qt/C++ DBUS API):
dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display
Comment 46 phd 2020-09-18 10:13:19 UTC
Or, even better, add focusDesktop() to Plasma and simply modify krunner/krunner.desktop:

Exec=dbus-send --type=method_call --dest=org.kde.plasmashell /PlasmaShell org.kde.plasmashell.PlasmaShell.focusDesktop; dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display

so that KRunner can still be opened even when Plasma is not running.
Comment 47 phd 2020-09-21 07:57:49 UTC
Proof-of-concept for the above (using wmctrl):

krunner/krunner.desktop:
...
Exec=wmctrl -ai `wmctrl -lxG | grep 'plasmashell' | grep -E -- '-1 +0 +0 ' | cut -d' ' -f1`; dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display

In fact using such a light and independent program like wmctrl to focus the desktop might be beneficial for speed. I'm not sure if requesting PlasmaShell to focus itself will always be fast. After all what we want is to simply tell X11/Wayland to move the focus to the desktop's window and send all the future input there.
Comment 48 Andreas Sturmlechner 2021-02-04 15:51:08 UTC
(In reply to David Redondo from comment #41)
> Git commit 0e575a20ef36532b5b40a40ea30f915976942477 by David Redondo.
> Committed on 11/09/2020 at 12:23.
> Pushed by davidre into branch 'master'.
> 
> Activate KRunner instead of running the binary

This is just to register a regression caused by this commit, where krunner is starting applications with cwd "/" instead of "~", confirmed on several systems to be fixed after reverting 0e575a20.

See also downstream bug: https://bugs.gentoo.org/767478
Comment 49 Nate Graham 2021-02-04 15:53:04 UTC
Can you please file a new bug report with that? Thanks!
Comment 50 ariasuni 2021-02-04 18:29:24 UTC
Seems to work well on KDE Neon. It runs in a VM, work perfectly when under no load, I tried to launch an upgrade at the same time and it still manages to be fast half of the time (I’m not sure how it translates in real use but that’s definitely a huge improvement).

It seems the dbus-send trick has been reverted:
https://invent.kde.org/plasma/plasma-workspace/-/commit/d544e7657fc756505670c0bfdfb6062a23f8798d

And that DBus activation is instead handled directly by kglobalaccel framework:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/609
Comment 51 Bug Janitor Service 2021-04-11 19:18:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/66
Comment 52 Dimo Fedortchenko 2021-07-16 10:32:38 UTC
I still have this issue in KDE 5.22.3, but I have discovered a very interesting "workaround" that completely solves the issue.

In the KRunner settings, if I change the Krunner Position on Screen to "top", it takes at least 3-5 seconds to open up no matter the enabled plugins.
However, changing it to "Center" opens Krunner immediately even with a bunch of plugins.

I have a Ryzen 9 3900x running in this case Fedora 34 (slowness has been around since I started in Fedora 31). 
However, on my machine I have discovered that my plasma bar is also very slow, like clicking the Volume icon is extremely slow and laggy, and my plasma bar is at the top of the screen, not sure if the slowness of the plasma bar causes krunner to also be slow when it opens at the top (where the plasma bar is). 

Or maybe it's completely unrelated, but in any case, if you're having KRunner open slowly, try to change it's placement to the Center of the screen, it solved the issue for me.
Comment 53 Till Schäfer 2021-07-23 20:57:44 UTC
I can confirm the workaround. Plasma does not feel sluggish here, but the difference for krunner is still remarkable. I have not been able to type something before krunner pops up, when using the center position. Before, the bug appeared regularly to me.
Comment 54 Nate Graham 2021-07-23 21:10:41 UTC
That is a very interesting observation. The difference between those settings is that the "Top" mode has to calculate its position every invocation using KWindowSystem APIs that take into account the Plasma Panel position and thickness. Perhaps these are heavyweight APIs that need to be made lighter. Or perhaps the position can be cashed and updated only if any of the conditions that affect them (screen resolution/scaling, panel position/thickness) get changed.
Comment 55 Podagric 2021-11-29 12:48:52 UTC
maybe this will help
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1230
Comment 56 John van Spaandonk 2022-01-26 08:05:43 UTC
This occurs especially  when I press the windows key and start typing, directly after I logged on.
It it the case that the krunner app must load from disk the first time it is run?
If this is so then perhaps it is possible to always load the krunner part on startup to prevent this.
Comment 57 Szőts Ákos 2022-01-27 21:55:58 UTC
Yes, what I always do in all my KDE installs is to autostart "/usr/bin/krunner --daemon". This causes KRunner to be loaded during KDE start-up and not to wait for it until the first time it's needed. I think it'd be nice to include it into default KDE installs, too.
Comment 58 Doug 2022-01-29 20:11:44 UTC
I believe the idea of not having it load immediately was to keep resource use down for default installs.  But maybe there could be a simple checkbox "enable KRunner at startup" or something similar.
Comment 59 Nate Graham 2022-04-27 04:07:36 UTC
For me, at this point it seems to be 100% fixed except for the very first invocation after login, where I still get a lost keystroke if I type very very quickly. https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1230 doesn't fix that, which tells me that it's not the DBus panel size querying that's a remaining bottleneck.

We could chase further performance improvements, or we could just auto-start KRunner at login.
Comment 60 Nate Graham 2022-08-22 23:24:49 UTC
Lowering priority due to the above.
Comment 61 Patrick Silva 2022-10-13 15:29:52 UTC
Same with kickoff. Sometimes it eats the first letter typed.

Operating System: Arch Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Graphics Platform: Wayland
Comment 62 Nate Graham 2022-11-19 04:58:32 UTC
This has been substantially improved even more, and now it only eats keystrokes when first launched if you're a lightning-fast typist. Reducing priority again.