<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Manajit,<div class=""><br class=""></div><div class="">The fix looks good to me. Can you port it to JDK 8u too, please?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Dmitry<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 7 Sep 2018, at 12:22, Manajit Halder <<a href="mailto:manajit.halder@oracle.com" class="">manajit.halder@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi Dmitry,</p><p class="">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). <br class="">
</p><p class="">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.</p><p class="">Please let me know if you have any other test scenarios to be
tested.</p><p class="">Thanks,<br class="">
Manajit<br class="">
</p>
<div class="moz-cite-prefix">On 05/09/18 4:47 PM, Dmitry Markov
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Hi Manajit,
<div class=""><br class="">
</div>
<div class="">Thank you for the clarification.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">Also it would be good to execute related AWT/Swing
jtreg tests to ensure that nothing is broken.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Dmitry <br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 4 Sep 2018, at 18:54, Manajit Halder <<a href="mailto:manajit.halder@oracle.com" class="" moz-do-not-send="true">manajit.halder@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi Dmitry,</p><p class="">Thanks for your reply. Please see my reply
inline.</p><p class="">Thanks,<br class="">
Manajit<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 01/09/18 12:02 AM,
Dmitry Markov wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
Hi Manajit,
<div class=""><br class="">
</div>
<div class="">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.</div>
</blockquote>
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.<br class="">
<blockquote type="cite" cite="mid:D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com" class="">
<div class=""><br class="">
</div>
<div class="">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?</div>
</blockquote>
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.<br class="">
<blockquote type="cite" cite="mid:D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com" class="">
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Dmitry <br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 31 Aug 2018, at 07:55, Manajit
Halder <<a href="mailto:manajit.halder@oracle.com" class="" moz-do-not-send="true">manajit.halder@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi All,<br class="">
<br class="">
Please review the fix for JDK12.<br class="">
<br class="">
<span style="font-family:"MS
Gothic"" class="">
</span>Bug: <br class="">
<a moz-do-not-send="true" href="https://bugs.openjdk.java.net/browse/JDK-8206392" class="">https://bugs.openjdk.java.net/browse/JDK-8206392</a></p><p class=""><a moz-do-not-send="true" href="https://bugs.openjdk.java.net/browse/JDK-8206392" class=""> </a><span style="font-family:"MS
Gothic"" class="">
</span>Webrev: <span style="font-family:"MS
Gothic"" class="">
</span><br class="">
<a href="http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/" moz-do-not-send="true" class="">http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/</a></p><p class="">Fix: <span style="font-family:"MS
Gothic"" class="">
</span><br class="">
Window ordering is not required if the
window doesn't own any other windows.</p>
Regards,<br class="">
Manajit </div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>