On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao <tsa...@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
