Qt5 xcb steals focus on click

I found Qt5 xcb is calling QWindow::requestActivate() without application direction. This happens when a Qt5 window is clicked, but it doesn't have focus when that click event is processed.

qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp
QXcbWindow::handleButtonPressEvent
        w->requestActivate();

commit fc663b5f9aae16fe6a03160e3eb148a5f742ac58
Author: Gunnar Sletta <gunnar.sletta@digia.com>
Date: Tue Jan 22 10:19:49 2013 +0100
Fix focus handling of native child widgets in xcb.
https://codereview.qt-project.org/#/c/45416/ (dev)

commit 3f99983e76d359cb45b15ae96150d4cc798b61c7
Author: Gunnar Sletta <gunnar.sletta@digia.com>
Date: Tue Jan 22 10:19:49 2013 +0100
Fix focus handling of native child widgets in xcb.
https://codereview.qt-project.org/#/c/48221/ (Cherry-picked into 5.0.2)

This is causing causing the desktop to change to that window, raising the window, and changing focus to that window. In general it is the window manager's job to make policy decisions such as click to raise and directing focus. I can understand cases when an application would want to call QWindow::requestActivate(), such as an urgent notification or something. But that should be rare and under application control. This is every click, anywhere in a Qt5 xcb window, and the only way an application can opt out of it is if it marks the window as not taking input at all.

The easiest way to demonstrate the behavior is to start a Qt5 application from a terminal, Control-Z in the terminal, click on the Qt5 application, then fg in the terminal, the desktop will switch to the window, it will raise, and it will take input focus. I happened to be using a debugger and finding it stealing focus. It could also be the case that the application is busy or swapping in from disk and not processing input until the user has moved on then surprise it just took focus where if it was responsive it wouldn't. In any case it isn't the toolkit's job to cause this behavior.

I've disabled the requestActivate and didn't see any problems.

I tried to e-mail the author Gunnar Sletta and reviewer Samuel Rodal to find out what the original problem was trying to solve but the e-mail was rejected.

I have a fix that will be submitted to codereview shortly and I'll add the link in a comment.