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

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/20180907/0bf4daac/attachment.html>