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> 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 >>>> >>> >> >
