Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10]
On Tue, 8 Mar 2022 20:32:53 GMT, Thiago Milczarek Sayao
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:
>
> Review adjustments
Marked as reviewed by arapte (Reviewer).
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10]
On Tue, 8 Mar 2022 20:32:53 GMT, Thiago Milczarek Sayao
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:
>
> Review adjustments
Marked as reviewed by kcr (Lead).
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10]
> 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:
Review adjustments
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/ee8ab1e2..42157fec
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=09
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=08-09
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
