Cocoa: processEvents does not always send posted events

The event dispatcher for the cocoa port relies on the
event loop source to fire for sending posted events. But when
dispatching events manually (not using exec mode) this does
not always trigger. This patch (discussed with brad) makes
sure we always call sendPostedEvents for this case

1 files changed, 8 insertions, 2 deletions

diff --git a/src/gui/kernel/qeventdispatcher_mac.mm b/src/gui/kernel/qeventdispatcher_mac.mm
index 15410ad..b4f3805 100644
--- a/src/gui/kernel/qeventdispatcher_mac.mm
+++ b/src/gui/kernel/qeventdispatcher_mac.mm
@@ -586,13 +586,14 @@ bool QEventDispatcherMac::processEvents(QEventLoop::ProcessEventsFlags flags)
         // application, we should not run or stop NSApplication; This will be
         // done from the application itself. And if processEvents is called
         // manually (rather than from a QEventLoop), we cannot enter a tight
-        // loop and block this call, but instead we need to return after one flush:
+        // loop and block this call, but instead we need to return after one flush.
+        // Finally, if we are to exclude user input events, we cannot call [NSApp run]
+        // as we then loose control over which events gets dispatched:
         const bool canExec_3rdParty = d->nsAppRunCalledByQt || ![NSApp isRunning];
         const bool canExec_Qt =
                 (flags & QEventLoop::DialogExec || flags & QEventLoop::EventLoopExec)
                 && !(flags & QEventLoop::ExcludeUserInputEvents);
 
-
         if (canExec_Qt && canExec_3rdParty) {
             // We can use exec-mode, meaning that we can stay in a tight loop until
             // interrupted. This is mostly an optimization, but it allow us to use
@@ -648,6 +649,11 @@ bool QEventDispatcherMac::processEvents(QEventLoop::ProcessEventsFlags flags)
                 }
             } while (!d->interrupt && event != nil);
 
+            // Be sure to flush the Qt posted events when not using mode
+            // (exec mode will always do this call from the event loop source):
+            if (!d->interrupt)
+                QCoreApplicationPrivate::sendPostedEvents(0, 0, d->threadData);
+
             // Since the window that holds modality might have changed while processing
             // events, we we need to interrupt when we return back the previous process
             // event recursion to ensure that we spin the correct modal session.