QWindow::destroy(): only reset QGuiApp::focus_window and friends as a last resort

Resetting focus_window and other internal QGuiApplication variables before
calling setVisible(false) and destroying the platform window means that the
platform window can't reason about whether or not it was the focus window
unless it can resolve that using native APIs. We should let the platform
window take care of resetting the focus window and related states, and
only execute our fallback logic if the plugin doesn't do the right
thing.

We also use QPA to update the state instead of modifying the internal
QGuiApplication variables directly, so that events and signals are
emitted as a result of the reset.

The QLineEdit test gets two added calls to processEvents(), since
assuming that activateWindow() is synchronous is not correct, and
would result in the QMenu resetting the focus window to 0 on destroy.

Task-number: QTBUG-46414
Change-Id: I562788393ed0ffd77d7a4be2279862322f721c1a
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/tests/auto/widgets/widgets/qlineedit/tst_qlineedit.cpp b/tests/auto/widgets/widgets/qlineedit/tst_qlineedit.cpp
index b46609c371..bf17625803 100644
--- a/tests/auto/widgets/widgets/qlineedit/tst_qlineedit.cpp
+++ b/tests/auto/widgets/widgets/qlineedit/tst_qlineedit.cpp
@@ -3570,7 +3570,7 @@ void tst_QLineEdit::task174640_editingFinished()
     QVERIFY(QTest::qWaitForWindowExposed(testMenu1));
     QTest::qWait(20);
     mw.activateWindow();
-
+    qApp->processEvents();
     delete testMenu1;
     QCOMPARE(editingFinishedSpy.count(), 0);
     QTRY_VERIFY(le1->hasFocus());
@@ -3582,6 +3582,7 @@ void tst_QLineEdit::task174640_editingFinished()
     QVERIFY(QTest::qWaitForWindowExposed(testMenu2));
     QTest::qWait(20);
     mw.activateWindow();
+    qApp->processEvents();
     delete testMenu2;
     QCOMPARE(editingFinishedSpy.count(), 1);
 }