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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
On Tue, 8 Mar 2022 13:12:03 GMT, Ambarish Rapte wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Capture event serial on process_key
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 780:
>
>> 778: }
>> 779:
>> 780: event_serial = 0;
>
> should we use GDK_CURRENT_TIME instead of 0 ?
> GDK_CURRENT_TIME is defined also as 0 and represent current time.
GDK_CURRENT_TIME is always 0, but it looks better. Changed it.
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1390:
>
>> 1388: // prevents activeWindows on WindowStage.java to be out of
>> order which may cause the FOCUS_DISABLED event
>> 1389: // to bring up the wrong window (it brings up the last which
>> will not be the real "last" if out of order).
>> 1390: gtk_window_present_with_time(GTK_WINDOW(gtk_widget),
>> event_serial);
>
> `event_serial` is not reset after use. I could observe that a stale value of
> `event_serial` gets reused several times.
> Steps to observe the behavior:
> 1. Print event_serial in this method
> 2. Run the sample program attached to JBS.
> 3. Press the "Click Me!" button
> 4. Answer YES on the Alert
> 5. Three stages should be visible on the screen.
> 6. Relocate such that all stages are visible
> 7. Click on 'This should be on Top' Stage
> 8. Click on "This is a stage with no owner' stage.
> 9. Click on StageTest icon in Taskbar. Keep repeating this step. The stage
> gains and looses focus and the same event_serial gets printed on terminal.
> => It does not look harmful behavior wise. But can observe that
> `event_serial` gets reused.
> Screenshot:
> src="https://user-images.githubusercontent.com/11330676/157248115-61240f6c-1710-461e-ba60-08e6210774e7.png;>
>
>
>
> Will it be good idea to reset it to 0/GDK_CURRENT_TIME and use something like,
>
>
> if (event_serial == GDK_CURRENT_TIME) {
> gtk_window_present(GTK_WINDOW(gtk_widget));
> } else {
> gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
> event_serial = GDK_CURRENT_TIME;
> }
>
>
> OR
>
>
> gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
> event_serial = GDK_CURRENT_TIME;
You're right, it can avoid other possible errors.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
On Tue, 25 Jan 2022 23:57:09 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:
>
> Capture event serial on process_key
The fix itself looks good. though I have a query. I did not observe any
mis-behaviour, so please check if the suggested change is required or not.
modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 780:
> 778: }
> 779:
> 780: event_serial = 0;
should we use GDK_CURRENT_TIME instead of 0 ?
GDK_CURRENT_TIME is defined also as 0 and represent current time.
modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1390:
> 1388: // prevents activeWindows on WindowStage.java to be out of
> order which may cause the FOCUS_DISABLED event
> 1389: // to bring up the wrong window (it brings up the last which
> will not be the real "last" if out of order).
> 1390: gtk_window_present_with_time(GTK_WINDOW(gtk_widget),
> event_serial);
`event_serial` is not reset after use. I could observe that a stale value of
`event_serial` gets reused several times.
Steps to observe the behavior:
1. Print event_serial in this method
2. Run the sample program attached to JBS.
3. Press the "Click Me!" button
4. Answer YES on the Alert
5. Three stages should be visible on the screen.
6. Relocate such that all stages are visible
7. Click on 'This should be on Top' Stage
8. Click on "This is a stage with no owner' stage.
9. Click on StageTest icon in Taskbar. Keep repeating this step. The stage
gains and looses focus and the same event_serial gets printed on terminal.
=> It does not look harmful behavior wise. But can observe that `event_serial`
gets reused.
Screenshot:
https://user-images.githubusercontent.com/11330676/157248115-61240f6c-1710-461e-ba60-08e6210774e7.png;>
Will it be good idea to reset it to 0/GDK_CURRENT_TIME and use something like,
if (event_serial == GDK_CURRENT_TIME) {
gtk_window_present(GTK_WINDOW(gtk_widget));
} else {
gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
event_serial = GDK_CURRENT_TIME;
}
OR
gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
event_serial = GDK_CURRENT_TIME;
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
On Tue, 25 Jan 2022 23:57:09 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:
>
> Capture event serial on process_key
This fix looks good. The test program for this bug reliably works now, and I
verified that it doesn't reintroduce
[JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) or
[JDK-8227366](https://bugs.openjdk.java.net/browse/JDK-8227366)
-
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 [v9]
On Tue, 25 Jan 2022 23:57:09 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:
>
> Capture event serial on process_key
I'll review and test it on a couple different systems.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Sat, 11 Dec 2021 00:32:06 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Minimize changes > > On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix. @kevinrushforth can you try this lastest version, please? - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
> 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:
Capture event serial on process_key
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/8630c557..ee8ab1e2
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=08
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=07-08
Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v8]
> 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:
Another approach.
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/196cecfe..8630c557
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=07
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=06-07
Stats: 22 lines in 3 files changed: 12 ins; 7 del; 3 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 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:
>
> Minimize changes
On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 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:
>
> Minimize changes
I ran the full systemTest and this test is not introducing any regression.
Also, the manual test attached in JBS works fine with this change.
modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 448:
> 446:
> 447: if (ctx != NULL) {
> 448:
You can probably remove this unnecessary change as this is only one change in
the file.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 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:
>
> Minimize changes
It would be nice to have this fix on jfx 17, since currently the issue causes
random windows to be focused and it's very confusing to the end user.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 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:
>
> 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
> 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
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/d51988c8..196cecfe
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=06
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=05-06
Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v4]
> 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 with a new target base due
to a merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains 23 additional commits
since the last revision:
- Prevent focus stealing
- Merge branch 'master' into
jdk_8271054_wrong_stage_gets_focused_after_modal_stage_creation
- Merge branch 'openjdk:master' into master
- Break if reach self
- handleFocusDisabled() should bring up the blocker window not the previous
one.
- Fix for JDK-8271054
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Merge pull request #18 from openjdk/master
Merge master
- Merge pull request #17 from openjdk/master
Pull from origin
- ... and 13 more: https://git.openjdk.java.net/jfx/compare/fa234fdd...eca324df
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/eb93b8b9..eca324df
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=03
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=02-03
Stats: 9848 lines in 801 files changed: 8688 ins; 160 del; 1000 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Tue, 12 Oct 2021 15:16:53 GMT, Pankaj Bansal wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
>> line 861:
>>
>>> 859:
>>> 860: // walk backwards to find a blocker
>>> 861: for (int i = activeWindows.size() - 1; i > 0; i--) {
>>
>> I think you will need to revert this part of the change.
>
> The test "WrongStageFocusWithApplicationModalityTest" passed for me on Ubuntu
> 20.04 VM. It failed first time, but when I re-ran it, it passed for me. I
> will run this change in Linux, Windows and Mac again today and report back.
@pankaj-bansal Wait, because I will rework it since it fails on JDK-8269429 and
JDK-8240640.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Tue, 12 Oct 2021 15:12:43 GMT, Kevin Rushforth wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Break if reach self
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
> line 861:
>
>> 859:
>> 860: // walk backwards to find a blocker
>> 861: for (int i = activeWindows.size() - 1; i > 0; i--) {
>
> I think you will need to revert this part of the change.
The test "WrongStageFocusWithApplicationModalityTest" passed for me on Ubuntu
20.04 VM. It failed first time, but when I re-ran it, it passed for me. I will
run this change in Linux, Windows and Mac again today and report back.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Wed, 22 Sep 2021 16:39:15 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:
>
> Break if reach self
The above test fails for me on Linux (Ubuntu 20.04 VM) as well. The manual test
case attached to
[JDK-8269429](https://bugs.openjdk.java.net/browse/JDK-8269429) also fails on
Linux. I think you will need a solution that doesn't modify the logic in
`WindowStage.java`.
modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
line 861:
> 859:
> 860: // walk backwards to find a blocker
> 861: for (int i = activeWindows.size() - 1; i > 0; i--) {
I think you will need to revert this part of the change.
-
Changes requested by kcr (Lead).
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Wed, 22 Sep 2021 16:39:15 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:
>
> 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal wrote: >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > > I am running a 20.04 VM. The test fails for me 60-70% of the time. I will > request someone in team to try this once. @pankaj-bansal Can you try the test attached to the JBS on macos and windows? Thanks. - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Wed, 22 Sep 2021 16:39:15 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:
>
> Break if reach self
I tested this using the manual test and looks ok to me. I ran the system tests
and it is not introducing any regression.
-
Marked as reviewed by pbansal (Committer).
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Wed, 22 Sep 2021 16:39:15 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:
>
> Break if reach self
Just a note, our javafx application at the company I work for is unusable with
javafx17 on Linux, windows go behind their owner or pops up wrongly. Can't use
17 line until it's fixed.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
> 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
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/850cfc8b..eb93b8b9
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=02
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=01-02
Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
I have proposed a different fix, but it might have concurrency issues and
probably others that should be investigated.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v2]
> 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:
handleFocusDisabled() should bring up the blocker window not the previous one.
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/3770f101..850cfc8b
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=01
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=00-01
Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 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
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
Docs states:
/*
* 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.
*/
But `WindowStage.java` actually does:
final void handleFocusDisabled() {
if (activeWindows.isEmpty()) {
return;
}
WindowStage window = activeWindows.get(activeWindows.size() - 1);
window.setIconified(false);
window.requestToFront();
window.requestFocus();
}
It brings up current activeWindows.size() - 1, not actually the MODAL blocker.
Seems wrong to me.
The event is born on `glass_window.cpp`:
```c++
mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
The current proposed code (which I will redo) blocks this line from being sent
(on non-virtual machines apparently). But commenting the
`jWindowNotifyFocusDisabled` should make the problem disappear (just to test
the theory).
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
I just tested this on my Ubuntu 20.04 VM and the problem still reproduces for
me with or without this fix.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal wrote: >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > > I am running a 20.04 VM. The test fails for me 60-70% of the time. I will > request someone in team to try this once. @pankaj-bansal Could you please re-test to confirm that it does not work on your VM? - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Sun, 15 Aug 2021 20:10:43 GMT, Thiago Milczarek Sayao wrote: > Weird, It works consistently for me on 20.04. Just tested again to be sure. I am running a 20.04 VM. The test fails for me 60-70% of the time. I will request someone in team to try this once. - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
Weird, It works consistently for me on 20.04. Just tested again to be sure.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
I ran the testcase attached in JBS with the fix multiple times. I can still
reproduce the issue on Ubuntu 20.0 almost always, so the fix does not seem to
work for me.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 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.
-
PR: https://git.openjdk.java.net/jfx/pull/598
