Hi Dmitry,
Thanks for the test scenarios. I have run all the AWT, Swing and JCK
automatic (open and closed) test cases along with manual test cases
related to Modal Dialog and ordering to ensure that fix doesn't cause
any regression. These JCK interactive test were run
"api/java_awt/interactive/ModalDialogTests.html",
"api/java_awt/interactive/FileDialogTests.html",
"api/java_awt/interactive/PageDialogTest.html" and
"api/java_awt/interactive/WindowTest.html" (tests toFront and toBack
between a window and a Frame).
For example, manual test
"open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java"
tests the scenario specified by you. Also there are many automatic test
cases in "open/test/jdk/java/awt/Modal/ToBack" and
"open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios
related to Modal Dialog and Frame/Window ordering.
Please let me know if you have any other test scenarios to be tested.
Thanks,
Manajit
On 05/09/18 4:47 PM, Dmitry Markov wrote:
Hi Manajit,
Thank you for the clarification.
Actually I worry about the case when a window is blocked by another
window or a modal dialog. We call orderAboveSiblings() for the blocker
window in several places, (e.g. inside setVisible(),
checkBlockingAndOrder(), etc.) and I guess some of these call might
fail with the new implementation of orderAboveSiblings(), (i.e. the
modal dialog might be placed behind the blocked window).
For example, let’s say we have the window which is blocked by the
modal dialog. What will be the position of the dialog (above or behind
the blocked window) once the window is activated? Please note: there
are several ways to activate the window: mouse click, toFront() call,
etc. Can you verify that these scenarios still work properly on the
build with your fix, please?
Also it would be good to execute related AWT/Swing jtreg tests to
ensure that nothing is broken.
Thanks,
Dmitry
On 4 Sep 2018, at 18:54, Manajit Halder <manajit.hal...@oracle.com
<mailto:manajit.hal...@oracle.com>> wrote:
Hi Dmitry,
Thanks for your reply. Please see my reply inline.
Thanks,
Manajit
On 01/09/18 12:02 AM, Dmitry Markov wrote:
Hi Manajit,
The current implementation assumes that orderAboveSiblings() places
the window in front of other windows located at the same level. The
proposed fix introduces new behaviour: if the window does not have
an owner and child windows it won’t be ordered, (i.e. in certain
conditions the window may be obscured by other windows even after
orderAboveSibling() execution). Most likely such approach will break
existed functionality - some windows will be incorrectly placed
behind other windows.
If I am not wrong windows (other than Window.Type.POPUP) are
already ordered in setVisible method at line no 632 while creation.
While debugging I observed that orderFront is called twice when the
window is displayed for the first time (in method setVisible and in
method orderAboveSiblings). Now when Key press COMMAND + ` is pressed
the current window receives windowDidBecomeMain notification and
which calls orderFront and also COMMAND + ` tries to order the window
above. Two time ordering the window when COMMAND + ` is pressed is
causing problem in case of multiple windows.
I am sorry, but the relationship between the original problem
described in the bug, (i.e. cycling through windows issue) and
implementation of orderAboveSiblings() is NOT clear. Can you explain
this?
This issue is a regression of JDK-8169589 introduced in JDK
release 8u131. 8169589 introduced new window ordering model and which
has introduced the cycling through window issue.
Thanks,
Dmitry
On 31 Aug 2018, at 07:55, Manajit Halder <manajit.hal...@oracle.com
<mailto:manajit.hal...@oracle.com>> wrote:
Hi All,
Please review the fix for JDK12.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8206392
<https://bugs.openjdk.java.net/browse/JDK-8206392>
Webrev:
http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/
<http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
Fix:
Window ordering is not required if the window doesn't own any
other windows.
Regards,
Manajit