Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
6.5.3
-
None
-
Windows 10 Desktop, MSVC 2019
Description
What was done?
- Ensure a QMessageBox has been shown and the parent window is minimized.
- Unminimize the window.
The first time this issue was observed it was in a "Really exit?" message box that was displayed when the main window was closed, so the message box was visible even though the application was minimized. From further testing, showing the message box and then minimizing and unminimizing also demonstrates the issue.
If the attached example is run, clicking the "Parented, MSWindowsFixedSizeDialogHint" button will open a message box. The application should then be minimized; if auto-minimize was enabled just wait the entered number of seconds. Otherwise, the application can be manually minimized via Windows Task Manager. Finally, restore the application.
What was seen?
The message box displays the title bar and not much else. Occasionally you get a sliver of background or even a thin line with a hint or icon or text.
What was expected?
When the window is restored the message box should return to it's previous size and position. The application user should always be able to read the box's text and interact with the buttons.
Additional Investigation
Both exec() and show() are vulnerable to this issue.
If the QMessageBox is created without a parent (is it's own window) then content is still displayed proper after unminimizing.
Calling setWindowModality() on the message box, regardless of argument, prevents the issue from occurring. Looking at the source code, setWindowModality() removes the window flag MSWindowsFixedSizeDialogHint that QMessageBox sets in it's constructor. Tried directly unsetting MSWindowsFixedSizeDialogHint instead of setting the modality and did not observe the issue.
The attached example includes buttons to show a QMessageBox with MSWindowsFixedSizeDialogHint set and no parent, and vice versa, to demonstrate that the issue only occurs when both factors are present.