Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.2.0, 5.9.1
Description
This is the issue:
If you have a modal window (M) and, while it's still showing, you spawn a window (W) containing a native widget child (C).
After we close M, C will stay blocked and ignore any user input.
This is what happens:
When W, is created, the QWindow constructor will simply prepend it in QGuiApplicationPrivate::window_list.
Its (W's) QWindowPrivate::blockedByModalWindow flag will be initialized to false, disregarding the actual presence of a modal window.
When C is initialized, instead, its window will be parented to W and QWindow::setParent will take care of the initialization by calling QGuiApplicationPrivate::updateBlockedStatus(this) which blocks C.
So W is unblocked while C is blocked.
When we close M, QGuiApplicationPrivate::hideModelWindow will try to unblock all of the QWindows by calling updateBlockedStatus recursively on the top level windows. But W is already unblocked, so it is skipped and the recursion doesn't reach the window of C, leaving it blocked.
One workaround is to call
windowHandle()->setParent( windowHandle()->parent() )
on the widget of W when it's created, but a correct fix would be to initialize updateBlockedStatus when the window is added to the QGuiApplication.