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

Reply via email to