It is possible for an application to trigger the unexpected result of NSModalResponseContinue from our call to NSAlert::runModal, by showing and hiding a modal dialog first, and processing events explicitly. This at best only flashes the native message box, at worst it triggers an assert from our processResponse function evaluating that response value as impossible (via Q_UNREACHABLE). We should never call processResponse with NSModalResponseContinue, but instead keep the modal loop running and the dialog visible. So introduce a wrapper to NSAlert::runModal that keeps calling that method until we get a result other than NSModalResponseContinue. Writing an auto test for this failed; a simple test didn't reproduce the assert; trying to place the opening of the native message box into a lambda that would be called by the event loop (simulating the button press from the bug report's reproducer) resulted in the native message box never closing and the test blocking (and still not triggering the assert). Fixes: QTBUG-114546 Pick-to: 6.5 6.6 Change-Id: Iab25eff55c48b103287d1881ac355e6cdd190f7a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>