A qml scene/view embedded into a QWidget looses the ability to get keyboard focus after clicking into QLineEdits and other QWidgets. Please use the embeddedinwidgets example from Qt as a basis for understanding my bugreport. When started I can type into the top QLineEdit, <tab> brings me to the two qml text boxes and I can type there. Alternatively I can click into the qml text boxes and start typing as well. Now once I click into one of the QLineEdits (or otherwise give focus to some QWidget), I can no longer set the keyboard focus to the Qml text boxes, neither by clicking, nor by pressing <tab>. Switching to a different window will restore everything, ie I can set the keyboard focus to the qml text box again. There is an upstream qt bug report ( https://bugreports.qt.io/browse/QTBUG-39362 ) but as I remarked there, switching the window manager solves the problem. I have tested it using IceWm and the windowmanager used in ubuntu unity, no problems there. Reproducible: Always Steps to Reproduce: Please use the embeddedinwidgets example from Qt as a basis for understanding my bugreport. When started I can type into the top QLineEdit, <tab> brings me to the two qml text boxes and I can type there. Alternatively I can click into the qml text boxes and start typing as well. Now once I click into one of the QLineEdits (or otherwise give focus to some QWidget), I can no longer set the keyboard focus to the Qml text boxes, neither by clicking, nor by pressing <tab>. Switching to a different window will restore everything, ie I can set the keyboard focus to the qml text box again. There is an upstream qt bug report ( https://bugreports.qt.io/browse/QTBUG-39362 ) but as I remarked there, switching the window manager solves the problem. I have tested it using IceWm and the windowmanager used in ubuntu unity, no problems there. I would be very grateful also for workarounds, ie. setting some window flag etc, as long as they are not too hackish.
Given how bad the embedding of QtQuick windows works I honestly doubt it's a KWin bug, we might just be more strict in some areas. But nevertheless I'll investigate.
I did some testing including running with openbox and can confirm that with openbox the behavior is different. But I'm not convinced that we have a KWin bug here, due to the following: One of the things I observed is that Qt doesn't update the state correctly even if the events are reported correctly. E.g: TestCase(16540)/(default) unknown: focusIn QSlider(0x197dd40, name = "horizontalSlider") TestCase(16540)/(default) unknown: focusIn QWindow(0x1970750) TestCase(16540)/(default) unknown: focusOut QSlider(0x197dd40, name = "horizontalSlider") In that state the horizontalSlider is rendered in active state although it's clearly not active given the reported events. On very first activation that works correctly. My test case was: 1. run the test applications from the linked bug report 2. focus on the embedded QWindow - observe slider becomes inactive 3. focus on the slider - observe slider becomes active 4. focus another window - observe slider becomes inactive 5. focus on the embedded window - observe slider becomes active The events in case 5 are the ones printed above: TestCase(16561)/(default) unknown: focusIn QSlider(0xf5eda0, name = "horizontalSlider") TestCase(16561)/(default) unknown: focusIn QWindow(0xf634b0) TestCase(16561)/(default) unknown: focusOut QSlider(0xf5eda0, name = "horizontalSlider") Qt clearly does not handle that case correctly. I'm not convinced that this is a KWin bug.
I feared so, thanks a lot for having a look anyway! There does not seem to be much interest in getting this fixed at the Qt side unfortunately.
Latest investigation in the upstream bug report show that this is a bug in Qt. When switching from a sub window to the parent window Qt asks the window manager to activate the window. As the window is already active, KWin ignores the request (see netinfo.cpp method RootInfo::changeActiveWindow branch for else if (c == workspace->mostRecentlyActivatedClient())). Given that the window manager is allowed to not do anything on the request, KWin's behavior is at least not wrong. I think it would be wrong to do the activation again for an active window. And Qt needs to manage input focus of it's embedded windows itself. This is not the task of a window manager. That it works with other window managers is pure chance: they just don't have a check to not activate already activated windows again.
*** Bug 360538 has been marked as a duplicate of this bug. ***