<AWT Dev> <AWT dev>[12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

Krishna Addepalli krishna.addepalli at oracle.com
Fri Sep 14 08:52:42 UTC 2018


Looks fine to me!

 

Thanks,

Krishna

 

From: Dmitry Markov 
Sent: Monday, September 10, 2018 6:06 PM
To: Manajit Halder <manajit.halder at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

 

Hi Manajit,

 

No problem, I will sponsor your commit to JDK 8u once it is ready and approved.

 

Thanks,

Dmitry 





On 10 Sep 2018, at 13:19, Manajit Halder <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

 

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 <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at 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 <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at 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 <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

 

Hi All,

Please review the fix for JDK12.



Bug: 
     https://bugs.openjdk.java.net/browse/JDK-8206392


Webrev: 

    HYPERLINK "http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/"http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/

Fix: 

    Window ordering is not required if the window doesn't own any other windows.

Regards,
Manajit 

 

 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/9d5aafa8/attachment.html>


More information about the awt-dev mailing list