On Thu, 3 Dec 2020 16:23:47 GMT, Johan Vos <j...@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
