4ec05ee2ad
QXcbWindow::requestActivateWindow() is called from the main thread, while handleMapNotifyEvent() is called from the XCB event thread. In a data race, handleMapNotifyEvent sets m_mapped to true, before requestActivateWindow() checks if it is false and sets m_deferredActivation to true. If that happens, a window activation is skipped until the next window systems event is processed. This is harmless in a normal application environment, where each mouse move causes window systems events to be processed. In an autotest environment, it causes flakiness, because an expected window activation may or may not happen. As a workaround, QApplicationPrivate::setActiveWindow() is frequently called after QWidget::activateWindow() or QWindow::requestActivate(), to set the active window on application level. In essence, this is setting expected outcome of a skipped deferred activation by force. This patch protects access to m_mapped and m_deferredActivation with a QMutex in both methods. That prevents the data race and ensures all deferred activations processed. Calling QApplicationPrivate::setActiveWindow() after activation on window/widget level becomes redundant. Task-number: QTBUG-119287 Pick-to: 6.5 Change-Id: I2eee69292afe0ef6381880a10d4e8483c2c7cbfa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit 2f6fe3a26843ff68c5d3f9af0a2fc3cce6caac22) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>