Dialog RFD does not work with winit MACOS

[TimonPost]

I am using RFD and the run_return function. If I open a dialog outside run-return it will open one frame and close directly i.e not block as expected. If I move the dialog into the run_return it stays open.

This behavior used to work on macos pre 0.27, so was wondering if there was a change that broke the behavior. And also it still works on windows!

If I log the FocusManager (link) in RFD, which is used here, I see the following:

Focus manager: false  true  true

With the log:

 log::warn!("Focus manager: {}  {}  {}", app.is_running(), app.get_window().is_some(), app.key_window().is_some());

Indicating the app is not running.

I have my repro example here:

https://github.com/rust-windowing/winit/compare/master...TimonPost:winit:timon/rfd-issue-run-return?expand=1

[msiglreith]

Which OS does it affect? I'm unable reproduce it on Windows fwiw.

[TimonPost]

Ah sorry, forgot to mention but its macos as references in the links as well. Windows does indeed work!

[rib]

This is getting into some sketchy territory in the MacOS backend...

On MacOS you have a global NSApp and CFRunLoop that may exist beyond the lifetime of a Winit EventLoop and is accessible to this external event loop, and rfd outside of Winit's run_return.

Internally Winit's MacOS backend has some global static Lazy<Handle> state that effectively lets it track state associated with the NSApp, including temporarily tracking the callback given to run_return.

Additionally when you create a new EventLoop the MacOS backend installs a RunLoopObserver for tracking when the event loop blocks to wait for events and when it wakes up. This observer will also try and dispatch corresponding events via the global Handle if it can find a valid callback - otherwise it will panic!. This panic! happens inside a fail-safe stop_app_on_panic wrapper around catch_unwind that will aim to call [NSApp stop] for this panic.

I'm not 100% sure of exactly what's going wrong in this specific example, but I did try reproducing something similar while I was looking at implementing the run, run_ondemand and pump_events APIs that were discussed recently here: #2706

I currently see something like:

1. Winit doesn't appear to ever uninstall the RunLoopObserver and doesn't anticipate that something else could potentially run the RunLoop.
2. [NSApp stop] will have been called as a means to stop the event loop and return from run_return which means that rfd is then trying to do things within a non-running NSApp.
3. Modal dialogs have a special "runModal" way of running a RunLoop which is effectively ignoring that the top-level NSApp is currently not actually "running" and this then kicks off Winit's observer callbacks and panic, and then re-"stop" the NSApp.

Some of this behaviour looks like it's been like this in Winit for a while, so I'm not sure atm why this usage model might have worked in the past - I have a feeling that might have involved a pretty big dose of luck :)

Maybe it will be enough to try and be more careful in Winit to consider that the RunLoop might get run outside of Winit but switching between two crates driving the main RunLoop in different ways (one via [NSApp run] and the other via a modal run seems like it could be risky.