RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina

[Kevin Rushforth]

On Thu, 3 Dec 2020 16:23:47 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use.
>> 
>> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743).
>> 
>> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated.
>> 
>> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems).
>> 
>> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing.
>> 
>> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a  terminal window as the FX application activates, deactivates, and reactivates.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 142:
> 
>> 140:     @Override
>> 141:     protected void notifyDidBecomeActive() {
>> 142:         super.notifyDidBecomeActive();
> 
> if an exception occurs in this method (which can happen in case the superclass eventHandler.handleDidBecomeActiveAction() throws an exception), the countDownLatch is never decreased, and the `wrappedRunnable` will never return. 
> I am not sure what the best approach is in this case. The Thread that waits for the reactivation is a daemon thread, but there might be other non-daemon threads lingering.
> One of the options is to set a timeout on the `reactivationLatch`. If the countdown didn't happen almost instantly, something is going wrong.

Good catch. It will block the starting of the app if this happens since we will never exit the nested event loop. Putting the call to `reactivationLatch.countDown();` in a try / finally seems best (although I had earlier considered a timeout as well).

> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 1079:
> 
>> 1077: {
>> 1078:     LOG("Java_com_sun_glass_ui_mac_MacApplication__1isNormalTaskbarApp");
>> 1079:     return isNormalTaskbarApp;
> 
> Are we guaranteed that this is not called before the runLoop is invoked? The `isNormalTaskbarApp` is only set to `YES` at line 536, and in theory, this method may get called before.

Yes, we only call it after runLoop (which is why the check is in the `wrappedRunnable`). A comment seems in order, so I'll add one.

-------------

PR: https://git.openjdk.java.net/jfx/pull/361