macOS: Don't condition deferred exec on specific NSAlert to be the mo…

…dal window

When a QMessageBox is created with setModal(true), the user can in theory
choose to show() it, and then return back to the main event loop, instead
of calling exec(). We tried to support that case via a single shot timer,
called on the next pass of the event loop, that checked if the applications'
current modal window was the alert, and if not, showed it at that point.

That logic failed when there were more than one alert show at the same
time.

We do maintain a stack of the modal sessions and their windows in the
Cocoa event dispatcher, so we could use that to check if a modal session
had been started for the alert's window, but a similar solution is to
just check the alert window's visible state.

Fixes: QTBUG-121557
Pick-to: 6.6 6.6.2 6.5
Change-Id: I6f52a53e8f678bb8a071e334a09ab30669d95bbf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
(cherry picked from commit 7edff3f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

src/plugins/platforms/cocoa/qcocoamessagedialog.mm

@@ -278,7 +278,7 @@ At this point the options() will reflect the specific dialog shown.
         // but also make sure that if the user returns to the main runloop
         // we'll run the modal dialog from there.
         QTimer::singleShot(0, this, [this]{
-            if (m_alert && NSApp.modalWindow != m_alert.window) {
+            if (m_alert && !m_alert.window.visible) {
                 qCDebug(lcQpaDialogs) << "Running deferred modal" << m_alert;
                 QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();
                 processResponse(runModal());