Hi Dmitry,
Sure, I can port it to JDK 8u, but would require your help in check-in,
as I don't have permission to check-in JDK 8u.
Thanks,
Manajit
On 09/09/18 3:35 PM, Dmitry Markov wrote:
Hi Manajit,
The fix looks good to me. Can you port it to JDK 8u too, please?
Thanks,
Dmitry
On 7 Sep 2018, at 12:22, Manajit Halder <manajit.hal...@oracle.com
<mailto:manajit.hal...@oracle.com>> wrote:
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
