On Thu, 21 Sep 2023 19:10:38 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> The fix for [JDK-8233678](https://bugs.openjdk.org/browse/JDK-8233678) added > a step to the NSApplication initialization to deactivate and then reactivate > the application. We trigger the deactivation the first time > applicationDidBecomeActive is called. We then trigger the reactivation the > when applicationDidResignActive is called after that. The initialization > logic in MacApplication spins up a nested event loop that waits for the > reactivation (a second call to applicationDidBecomeActive). > > Something in macOS 14 has changed that prevents the initial call to > applicationDidBecomeActive from being done until the application has finished > launching (notifyDidFinishLaunching). > > So the activation of the NSApplication is waiting for the launching to be > finished, but the nested event loop we spin up is blocking the completion of > launching until we get the activation. This is a classic deadlock. > > The good news, though, is the deactivation / reactivation of the application > no longer seems to be needed on macOS 14. The menus work fine without that > fix. > > The proposed solution is to check the version of macOS and only enable the > deactivation / reactivation logic on systems prior to macOS 14. This will > have the additional benefit of avoiding the brief flash when the app is first > launched (see [JDK-8257835](https://bugs.openjdk.org/browse/JDK-8257835)). > > This is a Draft PR with a few debugging statements. Once I get some feedback > that it works for more than just me, I'll remove the debugging statements and > then make it "rfr". Looks good, and testing on macOS 14 beta works with the proposed fix. Minor: if you update the copyright of license headers I'll reapprove again. ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1247#pullrequestreview-1642683755
