Bug 363892

Summary:	QtQuick Widgets embedded into a QWidget-based window cannot regain keyboard focus
Product:	[Plasma] kwin	Reporter:	Simon Schmeisser <s.schmeisser>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	max.schettler
Priority:	NOR
Version First Reported In:	5.5.5
Target Milestone:	---
Platform:	Kubuntu
OS:	Linux
URL:	http://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/embeddedinwidgets
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Simon Schmeisser 2016-06-03 11:36:38 UTC

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.

I would be very grateful also for workarounds, ie. setting some window flag etc, as long as they are not too hackish.

Comment 1 Martin Flöser 2016-06-03 13:30:14 UTC

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.

Comment 2 Martin Flöser 2016-06-03 13:48:14 UTC

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.

Comment 3 Simon Schmeisser 2016-06-03 14:20:39 UTC

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.

Comment 4 Martin Flöser 2016-08-27 15:42:30 UTC

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.

Comment 5 Martin Flöser 2016-08-29 08:50:59 UTC

*** Bug 360538 has been marked as a duplicate of this bug. ***