[Development] Calling QWindow::requestActivate after QWindow::show and before QTest::qWaitForWindowActive

[Liang Qi]

On Tue, 12 Aug 2025 at 02:53, EXT Mitch Curtis via Development
<development at qt-project.org> wrote:
>
> Hi,
>
> There's a discussion on https://codereview.qt-project.org/c/qt/qtdeclarative/+/666818 about whether we can standardise (by documenting in some form) that we shouldn't call requestActivate before qWaitForWindowActive. Essentially, existing code in tests looks like this:
>
>     window->show();
>     window->requestActivate();
>     QVERIFY(QTest::qWaitForWindowActive(window.data()));
>
> And would become this:
>
>     window->show();
>     QVERIFY(QTest::qWaitForWindowActive(window.data()));
>
> As Axel has explained, this causes race conditions on XCB, and apparently is redundant on all platforms:
>
> > To begin with, an autotest should be as close as possible to a real world scenario.
> > When the only window around is being shown, it is automatically activated. The additional window->requestActivate() redundant and not a real world scenario. This alone justifies its removal.

Based on doc, https://doc.qt.io/qt-6/qwindow.html

void QWindow::show() Shows the window.
void QWindow::requestActivate() Requests the window to be activated,
i.e. receive keyboard focus.

They are different things, show() will not make the window isActive(),
requestActivate() is needed to test keyboard input and etc afterwards.

Especially for Wayland, on Xcb or X11, perhaps our implementation
forced the window to be active when show() was called. We have tickets
in jira.

Best regards,
Liang

>
> I'd like to get agreement that this is the right thing to do on all platforms before proceeding (and then removing it en masse).
>
> Cheers.
>
> Confidential
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development