kotschak/qelectrotech-source-mirror
0
0
Fork 0
mirror of https://github.com/qelectrotech/qelectrotech-source-mirror.git synced 2026-10-09 21:54:13 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Wait for the window to be active in the menu bar keyboard tests

Browse Source 
tst_menubarkeyboard sends Alt+F and F10 right after the test window is
exposed, then sleeps 300 ms and checks. Menu mnemonics and the F10
shortcut (a Qt::WindowShortcut) only fire in the active window, and
being exposed does not mean being active: on a loaded Xvfb, or on macOS
with another application in front, activation arrives later and the key
is dropped. The sleep comes after the key and cannot help. This made
shortcutOpensMenuBar fail on #1420's Linux CI ("F10 did not activate the
menu bar") while the same base passed on #1421 and #1422, and made the
Alt+F control fail in 1 of about 33 local runs with the cocoa platform.

Every test now waits for the window to be active before pressing a key
(qWaitForWindowActive, with its own failure message), and the two tests
that expect a menu poll for it with QTRY_VERIFY2 instead of a fixed
sleep. plainF10DoesNothingInQt keeps its 300 ms: it checks that nothing
happens, which cannot be polled for; with the window now active first,
that check can no longer pass merely because the key went nowhere.

Test-only change. Checked: with a second window active, F10 sent to the
exposed but inactive window does not activate its menu bar (offscreen
and cocoa); once it is active, it does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Beat Hangartner
2026-10-09 14:30:27 +02:00
parent ff35d0dc69
commit 7866a37f14
1 changed files with 19 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/qttest/tst_menubarkeyboard.cpp
+19 -7
View File
@@ -72,6 +72,18 @@ QMainWindow *makeWindow(QMenu **file_menu)
return w;
}
/*
Menu mnemonics and the F10 shortcut (a Qt::WindowShortcut) only fire
in the active window. Being exposed is not enough: on a loaded Xvfb or
with another application in front on macOS, activation arrives later,
and a key sent before it is dropped. Every test waits for activation
before pressing anything.
*/
bool waitForActiveWindow(QMainWindow *w)
{
return QTest::qWaitForWindowExposed(w) && QTest::qWaitForWindowActive(w);
}
}
/*
@@ -95,12 +107,12 @@ void TstMenuBarKeyboard::altLetterOpensMenu()
{
QMenu *file = nullptr;
QScopedPointer<QMainWindow> w(makeWindow(&file));
QVERIFY(QTest::qWaitForWindowExposed(w.data()));
QVERIFY2(waitForActiveWindow(w.data()),
"the test window never became active");
QTest::keyClick(w.data(), Qt::Key_F, Qt::AltModifier);
QTest::qWait(300);
QVERIFY2(file->isVisible(),
QTRY_VERIFY2(file->isVisible(),
"control failed: Alt+F did not open a menu, so this environment "
"cannot judge any of the keyboard tests below");
}
@@ -113,7 +125,8 @@ void TstMenuBarKeyboard::plainF10DoesNothingInQt()
{
QMenu *file = nullptr;
QScopedPointer<QMainWindow> w(makeWindow(&file));
QVERIFY(QTest::qWaitForWindowExposed(w.data()));
QVERIFY2(waitForActiveWindow(w.data()),
"the test window never became active");
QTest::keyClick(w.data(), Qt::Key_F10, Qt::NoModifier);
QTest::qWait(300);
@@ -139,7 +152,7 @@ void TstMenuBarKeyboard::shortcutOpensMenuBar()
QMenu *file = nullptr;
QScopedPointer<QMainWindow> holder(makeWindow(&file));
QMainWindow *w = holder.data();
QVERIFY(QTest::qWaitForWindowExposed(w));
QVERIFY2(waitForActiveWindow(w), "the test window never became active");
auto *shortcut = new QShortcut(QKeySequence(Qt::Key_F10), w);
shortcut->setContext(Qt::WindowShortcut);
@@ -153,9 +166,8 @@ void TstMenuBarKeyboard::shortcutOpensMenuBar()
});
QTest::keyClick(w, Qt::Key_F10, Qt::NoModifier);
QTest::qWait(300);
QVERIFY2(w->menuBar()->activeAction() != nullptr,
QTRY_VERIFY2(w->menuBar()->activeAction() != nullptr,
"F10 did not activate the menu bar");
QCOMPARE(w->menuBar()->activeAction()->text(), QStringLiteral("&File"));
}