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

[Manajit Halder]

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

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