This bug only affects the Windows port.
Envision a real-time application that needs to update and repaint its main window as quickly as possible when there is time available.
Create a new QWidget-based top-level window. Now create a QTimer, so that we can use QApplication::exec() and still render one frame upon each QTimer::timeout() signal. So use QTimer::start(0), or a value from 0 - 20, for instance. The higher the value, the greater the performance hit to our real-time app, so this needs to be low.
Now imagine your app has a QPushButton, that when clicked, shows a modal QDialog box via QDialog::exec(). This dialog box will never update because of the active QTimer. For instance, say there is a listbox with several items in it. When you click to select one, the screen does not update to show that it was selected. The application is not frozen, however. A strange side effect is that by resizing the dialog box, it does update and you can see your item was selected after all.
Now if you change the QTimer to start(200), everything works fine, but your application is limited to a meager 5fps, if your application rendered one frame per QTimer::timeout().
I've attached a minimal example source code project that does exactly this, and nothing else.