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

[Thiago Milczarek Sayao]

On Mon, 1 Nov 2021 16:46:34 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:
> 
>   Minimize changes

The ideal fix would be to know the original event and save it's X11 serial event number to pass to `gtk_window_present_with_time` so "focus stealing" would not happen. But I don't think it's possible because it should save the "event serial number" on the original mouse click to open a window (for example). As you have thought, many "original event" combinations are possible.

The fix just reorders the `WindowStage.activeWindows` by calling `FOCUS_GAINED`. So when `FOCUS_DISABLED` happens it focuses the correct window. Please not that with this fix there are extra calls to FOCUS events and reorder of `WindowStage.activeWindows` (although they are not expensive).

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

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