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

[Thiago Milczarek Sayao]

> 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&pr=598&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=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