Bug 385693 - krunner text input broken with wayland
Summary: krunner text input broken with wayland
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.11.0
Platform: Gentoo Packages Linux
: NOR major
Target Milestone: ---
Assignee: Kai Uwe Broulik
URL:
Keywords: usability, wayland
: 385773 388179 389557 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-13 11:20 UTC by Märt Bakhoff
Modified: 2018-01-31 11:20 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
remove-krunner-event-override-5.11.4.patch (2.69 KB, patch)
2017-12-27 18:50 UTC, Märt Bakhoff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Märt Bakhoff 2017-10-13 11:20:14 UTC
Steps:
1) start plasma wayland session from sddm
2) press alt+f2, krunner appears, text field has focus
3) type "dolphin"

Expected result: 
Krunner text field contains "dolphin".

Actual result:
Each typed character replaces the previous character: "" -> "d" -> "o" -> "l" etc. Backspace does not work. 

Reproduced with plasma 5.11, frameworks 5.38, qt 5.9.2 on gentoo/systemd ~amd64.
Krunner was working in plasma 5.10 wayland. 
Krunner works with plasma 5.11 + x11. 
Other applications, such as konsole, accept input normally with wayland.

Let me know if I can help in any way.
Comment 1 Nate Graham 2017-10-15 23:23:37 UTC
*** Bug 385773 has been marked as a duplicate of this bug. ***
Comment 2 yellowhat46 2017-11-01 11:12:44 UTC
Exactly same behavior for me.
Plasma 5.11.2, Qt 5.9.2, Gentoo/systemd ~amd64

Thanks
Comment 3 yellowhat46 2017-11-08 19:49:13 UTC
Same problem with 5.11.3 and 5.39.0 kde framework.
Comment 4 Nate Graham 2017-11-19 05:24:59 UTC
Marking as Major, since this makes KRunner more or less unusable in a Wayland session.
Comment 5 David Edmundson 2017-11-30 08:25:09 UTC
Was a Qt bug that is since fixed.
Try with Qt5.10 and reopen if you still have an issue.
Comment 6 Patrick Silva 2017-12-02 13:59:25 UTC
I'm testing qt 5.10 rc2 on Arch Linux.
The problem persists.
Comment 7 Märt Bakhoff 2017-12-12 09:26:08 UTC
Problem persists: qt 5.10, frameworks 5.41, plasma 5.11.4
Comment 8 Patrick Silva 2017-12-24 10:35:41 UTC
*** Bug 388179 has been marked as a duplicate of this bug. ***
Comment 9 Fabian Vogt 2017-12-24 10:51:34 UTC
(In reply to David Edmundson from comment #5)
> Was a Qt bug that is since fixed.
> Try with Qt5.10 and reopen if you still have an issue.

Still exists. What's the commit which was supposed to fix it?
Comment 10 Märt Bakhoff 2017-12-26 19:06:25 UTC
I interrogated krunner with gdb and found some potentially useful information:

The query in the text field is overwritten here:

plasma-workspace-5.11.4/krunner/view.cpp:380
375 void View::query(const QString &term)
376 {
377     setVisible(true);
378
379     m_qmlObj->rootObject()->setProperty("runner", QString());
380     m_qmlObj->rootObject()->setProperty("query", term);
381 }

The query method is triggered by a QDBusActivateObjectEvent, which does a QDBusActivateObjectEvent::placeMetaCall

The metacall seems to be sent from plasma-workspace-5.11.4/shell/desktopview.cpp:241:
240 org::kde::krunner::App krunner(interface, QStringLiteral("/App"), QDBusConnection::sessionBus());
241 krunner.query(text);

Debugging plasmashell shows that this snippet runs every time when krunner text is overwritten and the argument text has size() == 1.

Another observation:
1) open konsole, focus it
2) type alt+f2, "d"
3) click on krunner text field to focus it
4) click on konsole to focus it (krunner doesn't close)
5) click on krunner text field to focus it
6) type "olphin" -> text field now contains "dolphin" as expected
Comment 11 Fabian Vogt 2017-12-26 20:41:16 UTC
(In reply to Märt Bakhoff from comment #10)
> The query in the text field is overwritten here:
> 
> plasma-workspace-5.11.4/krunner/view.cpp:380
> 375 void View::query(const QString &term)
> 376 {
> 377     setVisible(true);
> 378
> 379     m_qmlObj->rootObject()->setProperty("runner", QString());
> 380     m_qmlObj->rootObject()->setProperty("query", term);
> 381 }
> 
> The query method is triggered by a QDBusActivateObjectEvent, which does a
> QDBusActivateObjectEvent::placeMetaCall
> 
> The metacall seems to be sent from
> plasma-workspace-5.11.4/shell/desktopview.cpp:241:
> 240 org::kde::krunner::App krunner(interface, QStringLiteral("/App"),
> QDBusConnection::sessionBus());
> 241 krunner.query(text);

Ok, so it looks like krunner doesn't get focus early enough and plasmashell still gets all the key events.
Comment 12 Märt Bakhoff 2017-12-27 18:50:09 UTC
Created attachment 109547 [details]
remove-krunner-event-override-5.11.4.patch

Removing the method `bool event(QEvent* event) override` from the krunner view fixes the issue for me (see remove-krunner-event-override-5.11.4.patch). The method seems to be a workaround for some old bug, so removing it may cause other issues.
Comment 13 Fabian Vogt 2017-12-30 17:36:16 UTC
(In reply to Märt Bakhoff from comment #12)
> Created attachment 109547 [details]
> remove-krunner-event-override-5.11.4.patch
> 
> Removing the method `bool event(QEvent* event) override` from the krunner
> view fixes the issue for me (see
> remove-krunner-event-override-5.11.4.patch). The method seems to be a
> workaround for some old bug, so removing it may cause other issues.

I tried this, it does not help here.

It seems to be a race condition. The first press gets sent by plasmashell to the krunner dbus service, which then starts opening the view.
Then the subsequent presses arrive, but as krunner is not completely opened yet it doesn't have focus and plasmashell still sends the single keypresses to krunner over dbus.
Comment 14 Fabian Vogt 2017-12-30 22:32:57 UTC
This is a more general issue with krunner.
It acquires actual focus too late, even when it's already shown completely, the keyboard focus is missing.

Here you can see openQA typing "xterm" after matching the fully opened krunner on the screen. The result is "erm" in the input line.
Comment 15 Fabian Vogt 2017-12-30 22:33:42 UTC
(In reply to Fabian Vogt from comment #14)
> Here you can see openQA typing "xterm" after matching the fully opened
> krunner on the screen. The result is "erm" in the input line.

Apparently I forgot the URL:

https://openqa.opensuse.org/tests/570421#step/kate/1 (the "erm" result is visible in the next step)
Comment 16 Märt Bakhoff 2017-12-31 11:05:34 UTC
Thanks for your insight Fabian. I'm wondering if there are two separate issues here. 

In my case, krunner never receives keyboard focus at all. Pressing alt+f2 makes krunner visible, but all key events still go to plasmashell. This happens whether there is a delay between alt+f2 and typing the command or not. 

I tried to remove the code in plasmashell that activates krunner over dbus. Then alt+f2 still opens krunner, but nothing can be written to the query box at all. Clicking on the query box focuses it and it starts working normally.

If the race condition was about which window receives the key events, then should't waiting for krunner to open completely affect the result? It doesn't in my case.
Comment 17 Nate Graham 2018-01-28 21:23:15 UTC
*** Bug 389557 has been marked as a duplicate of this bug. ***
Comment 18 Aleix Pol 2018-01-30 23:59:04 UTC
This works for me, on Plasma/5.12 branch. Inspired on Märt's approach.
https://phabricator.kde.org/D10197
Comment 19 Aleix Pol 2018-01-31 11:20:15 UTC
Git commit fc5a45403025286fed063273f958ef0aa04f7f30 by Aleix Pol.
Committed on 31/01/2018 at 11:20.
Pushed by apol into branch 'Plasma/5.12'.

Fix krunner's alt+f2 on wayland

Summary:
Don't go through the workaround introduced for X11 that makes it go mental.

Test Plan: Have been a happy krunner user since

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: ngraham, davidedmundson, plasma-devel

Tags: #plasma

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

M  +1    -60   krunner/view.cpp
M  +0    -4    krunner/view.h

https://commits.kde.org/plasma-workspace/fc5a45403025286fed063273f958ef0aa04f7f30