macOS: Improve event queuing (#3708)

* Use AppKit's internal queuing mechanisms

This allows events to be queued in a more consistent order, they're now
interleaved with events that we handle immediately (like redraw events),
instead of being handled afterwards.

* Only queue events if necessary

This makes the call stack / backtraces easier to understand whenever
possible, and generally improves upon the order in which events are
delivered.

src/platform_impl/macos/observer.rs

@@ -1,19 +1,26 @@
+//! Utilities for working with `CFRunLoop`.
+//!
+//! See Apple's documentation on Run Loops for details:
+//! <https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html>
+use std::cell::Cell;
 use std::ffi::c_void;
 use std::panic::{AssertUnwindSafe, UnwindSafe};
 use std::ptr;
 use std::rc::Weak;
 use std::time::Instant;
 
-use core_foundation::base::{CFIndex, CFOptionFlags, CFRelease};
+use block2::Block;
+use core_foundation::base::{CFIndex, CFOptionFlags, CFRelease, CFTypeRef};
 use core_foundation::date::CFAbsoluteTimeGetCurrent;
 use core_foundation::runloop::{
-    kCFRunLoopAfterWaiting, kCFRunLoopBeforeWaiting, kCFRunLoopCommonModes, kCFRunLoopExit,
-    CFRunLoopActivity, CFRunLoopAddObserver, CFRunLoopAddTimer, CFRunLoopGetMain,
+    kCFRunLoopAfterWaiting, kCFRunLoopBeforeWaiting, kCFRunLoopCommonModes, kCFRunLoopDefaultMode,
+    kCFRunLoopExit, CFRunLoopActivity, CFRunLoopAddObserver, CFRunLoopAddTimer, CFRunLoopGetMain,
     CFRunLoopObserverCallBack, CFRunLoopObserverContext, CFRunLoopObserverCreate,
     CFRunLoopObserverRef, CFRunLoopRef, CFRunLoopTimerCreate, CFRunLoopTimerInvalidate,
     CFRunLoopTimerRef, CFRunLoopTimerSetNextFireDate, CFRunLoopWakeUp,
 };
 use objc2_foundation::MainThreadMarker;
+use tracing::error;
 
 use super::app_delegate::ApplicationDelegate;
 use super::event_loop::{stop_app_on_panic, PanicInfo};
@@ -84,10 +91,20 @@ extern "C" fn control_flow_end_handler(
     }
 }
 
+#[derive(Debug)]
 pub struct RunLoop(CFRunLoopRef);
 
+impl Default for RunLoop {
+    fn default() -> Self {
+        Self(ptr::null_mut())
+    }
+}
+
 impl RunLoop {
-    pub unsafe fn get() -> Self {
+    pub fn main(mtm: MainThreadMarker) -> Self {
+        // SAFETY: We have a MainThreadMarker here, which means we know we're on the main thread, so
+        // scheduling (and scheduling a non-`Send` block) to that thread is allowed.
+        let _ = mtm;
         RunLoop(unsafe { CFRunLoopGetMain() })
     }
 
@@ -114,9 +131,79 @@ impl RunLoop {
         };
         unsafe { CFRunLoopAddObserver(self.0, observer, kCFRunLoopCommonModes) };
     }
+
+    /// Submit a closure to run on the main thread as the next step in the run loop, before other
+    /// event sources are processed.
+    ///
+    /// This is used for running event handlers, as those are not allowed to run re-entrantly.
+    ///
+    /// # Implementation
+    ///
+    /// This queuing could be implemented in the following several ways with subtle differences in
+    /// timing. This list is sorted in rough order in which they are run:
+    ///
+    /// 1. Using `CFRunLoopPerformBlock` or `-[NSRunLoop performBlock:]`.
+    ///
+    /// 2. Using `-[NSObject performSelectorOnMainThread:withObject:waitUntilDone:]` or wrapping the
+    ///    event in `NSEvent` and posting that to `-[NSApplication postEvent:atStart:]` (both
+    ///    creates a custom `CFRunLoopSource`, and signals that to wake up the main event loop).
+    ///
+    ///    a. `atStart = true`.
+    ///
+    ///    b. `atStart = false`.
+    ///
+    /// 3. `dispatch_async` or `dispatch_async_f`. Note that this may appear before 2b, it does not
+    ///    respect the ordering that runloop events have.
+    ///
+    /// We choose the first one, both for ease-of-implementation, but mostly for consistency, as we
+    /// want the event to be queued in a way that preserves the order the events originally arrived
+    /// in.
+    ///
+    /// As an example, let's assume that we receive two events from the user, a mouse click which we
+    /// handled by queuing it, and a window resize which we handled immediately. If we allowed
+    /// AppKit to choose the ordering when queuing the mouse event, it might get put in the back of
+    /// the queue, and the events would appear out of order to the user of Winit. So we must instead
+    /// put the event at the very front of the queue, to be handled as soon as possible after
+    /// handling whatever event it's currently handling.
+    pub fn queue_closure(&self, closure: impl FnOnce() + 'static) {
+        extern "C" {
+            fn CFRunLoopPerformBlock(rl: CFRunLoopRef, mode: CFTypeRef, block: &Block<dyn Fn()>);
+        }
+
+        // Convert `FnOnce()` to `Block<dyn Fn()>`.
+        let closure = Cell::new(Some(closure));
+        let block = block2::RcBlock::new(move || {
+            if let Some(closure) = closure.take() {
+                closure()
+            } else {
+                error!("tried to execute queued closure on main thread twice");
+            }
+        });
+
+        // There are a few common modes (`kCFRunLoopCommonModes`) defined by Cocoa:
+        // - `NSDefaultRunLoopMode`, alias of `kCFRunLoopDefaultMode`.
+        // - `NSEventTrackingRunLoopMode`, used when mouse-dragging and live-resizing a window.
+        // - `NSModalPanelRunLoopMode`, used when running a modal inside the Winit event loop.
+        // - `NSConnectionReplyMode`: TODO.
+        //
+        // We only want to run event handlers in the default mode, as we support running a blocking
+        // modal inside a Winit event handler (see [#1779]) which outrules the modal panel mode, and
+        // resizing such panel window enters the event tracking run loop mode, so we can't directly
+        // trigger events inside that mode either.
+        //
+        // Any events that are queued while running a modal or when live-resizing will instead wait,
+        // and be delivered to the application afterwards.
+        //
+        // [#1779]: https://github.com/rust-windowing/winit/issues/1779
+        let mode = unsafe { kCFRunLoopDefaultMode as CFTypeRef };
+
+        // SAFETY: The runloop is valid, the mode is a `CFStringRef`, and the block is `'static`.
+        unsafe { CFRunLoopPerformBlock(self.0, mode, &block) }
+    }
 }
 
-pub fn setup_control_flow_observers(panic_info: Weak<PanicInfo>) {
+pub fn setup_control_flow_observers(mtm: MainThreadMarker, panic_info: Weak<PanicInfo>) {
+    let run_loop = RunLoop::main(mtm);
     unsafe {
         let mut context = CFRunLoopObserverContext {
             info: Weak::into_raw(panic_info) as *mut _,
@@ -125,7 +212,6 @@ pub fn setup_control_flow_observers(panic_info: Weak<PanicInfo>) {
             release: None,
             copyDescription: None,
         };
-        let run_loop = RunLoop::get();
         run_loop.add_observer(
             kCFRunLoopAfterWaiting,
             CFIndex::min_value(),