1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

macOS: Don't condition deferred exec on specific NSAlert to be the modal window

Browse Source 
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 7edff3f15ae21c2310437e0711f84442a21cb6a1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Tor Arne Vestbø 2024-01-26 15:33:46 +01:00 committed by Qt Cherry-pick Bot
parent 7927145625
commit c967ee08c8
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/plugins/platforms/cocoa/qcocoamessagedialog.mm
View File

@ -278,7 +278,7 @@ bool QCocoaMessageDialog::show(Qt::WindowFlags windowFlags, Qt::WindowModality w
// 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());