Steps to reproduce: 1. open KRunner through alt+space 2. dismiss KRunner through Escape 3. open KRunner through alt+space Actual behavior: Krunner slides in and out immediately Expected behavior: KRunner slides in and can be used This only happens with Escape key, if dismissed through close button click, or click outside or launching an item, KRunner opens fine again. This might be an issue in Qt 5.9
I modified RunCommand.qml to contain Keys.onEscapePressed: { runnerWindow.visible = false console.log("escape pressed") } and as soon as Escape is pressed the log is printed till eternity. I assume a Qt bug, will create minimal test case tomorrow.
Upstream bug reported: https://bugreports.qt.io/browse/QTBUG-61930
Workaround in KWayland: https://phabricator.kde.org/D6683
Git commit 98e5d269a110dca9cae1e4ed2bb3051f02a69bff by Martin Flöser. Committed on 16/07/2017 at 14:25. Pushed by graesslin into branch 'master'. [server] Send keyboard leave when client destroys the focused surface Summary: This is a change inspired by https://bugreports.qt.io/browse/QTBUG-61930. When Qt closes a window due to a key press event it starts to repeat the event as KWayland does not send a keyboard leave event. Weston on the other hand does send out the keyboard leave. In my opinion it doesn't make much sense to send out the keyboard leave in this situation and in my opinion that is a client bug, but if it makes clients happy we can send them the keyboard leave. Similar this should be done for pointer, touch, etc. Test Plan: Run the example added to the Qt bug and it worked fine Reviewers: #frameworks, #plasma Subscribers: plasma-devel Tags: #plasma_on_wayland, #frameworks Differential Revision: https://phabricator.kde.org/D6683 M +2 -1 autotests/client/test_wayland_seat.cpp M +4 -1 src/server/keyboard_interface.cpp M +1 -0 src/server/resource.cpp M +10 -0 src/server/resource.h https://commits.kde.org/kwayland/98e5d269a110dca9cae1e4ed2bb3051f02a69bff