RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]

[Kevin Rushforth]

On Wed, 22 Sep 2021 16:39:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Found the problem thru this path:
>> 
>> **WindowStage.java**
>> 
>>     final void handleFocusDisabled() {
>>         if (activeWindows.isEmpty()) {
>>             return;
>>         }
>>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>>         window.setIconified(false);
>>         window.requestToFront();
>>         window.requestFocus();
>>     }
>> 
>> 
>> **glass_window.cpp**
>> 
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>    ...
>> 
>>     if (jwindow) {
>>         if (!event->in || isEnabled()) {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         } else {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         }
>>     }
>> }
>> 
>> 
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
>> 
>> The docs states:
>> 
>>     /**
>>      * Enables or disables the window.
>>      *
>>      * A disabled window is unfocusable by definition.
>>      * Also, key or mouse events aren't generated for disabled windows.
>>      *
>>      * When a user tries to activate a disabled window, or the window gets
>>      * accidentally brought to the top of the stacking order, the window
>>      * generates the FOCUS_DISABLED window event. A Glass client should react
>>      * to this event and bring the currently active modal blocker of the
>>      * disabled window to top by calling blocker's minimize(false), toFront(),
>>      * and requestFocus() methods. It may also 'blink' the blocker window to
>>      * further attract user's attention.
>>      *
>>      .....
>> 
>> 
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
>> 
>> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break if reach self

This fix reintroduced [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) on macOS. With the patch applied I get the following failure:


test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest > testWindowFocusByClosingAlerts FAILED
    java.lang.AssertionError: Timeout: Alerts not closed, wrong focus
        at org.junit.Assert.fail(Assert.java:91)
        at org.junit.Assert.assertTrue(Assert.java:43)
        at test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest.waitForLatch(WrongStageFocusWithApplicationModalityTest.java:82)
        at test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest.testWindowFocusByClosingAlerts(WrongStageFocusWithApplicationModalityTest.java:70)

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

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