Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.7.1, 5.15.0, 6.5
-
None
-
MacOS 10.15.7
Description
The issue in QTBUG-56746 introduced in 5.7.1 and affecting later versions (at least as of 5.15.0) sometimes, but not always, causes any direct use of `NSOpenPanel` with `runModal` to return immediately. It flickers on the screen for just a brief moment. The problem is deterministic for a call site, but different callers of the same dialog code can have different results, presumably to do with this internal interrupt flag state.
Looking at this change set:
https://codereview.qt-project.org/c/qt/qtbase/+/176020
This appears to be because the internal `interrupt` flag gets set more or less permanently. The fix for QTBUG-56746 introduced a function `QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag` that is used internally, but is not part of the public API for user code to call. The QT native dialog code (e.g. in `qcocoafiledialoghelper.mm`) sets the flag itself again after use with a call to `QAbstractEventDispatcher::instance()->interrupt();` regardless of whether it was set already or not.
So this change seems to have fixed the internal QT use of native dialogs but leaves code that uses native dialogs directly broken. Previously, an extra call to `qApp->processEvents` prior to `runModal` cleared this interrupt flag and allowed the dialog to work. I'm not sure if there is any work around as the flag is internal state, the `QCocoaEventDispatcher` is not public API, and even given the header definitions the symbols are local in libqcocoa.dylib so I haven't been able to link them or access dynamically with `dlsym`. I don't see a function in `QAbstractEventDispatcher` to clear the interrupt as there is for setting it.