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 <manajit.hal...@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 <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> >>>>>>> <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 >>>>>> >>>>> >>>> >>> >> >