On Fri, 19 May 2023 11:18:16 GMT, Alexander Zvegintsev <azveg...@openjdk.org>
wrote:
>> Issue was bug6889007.java was causing a timeout issue on mac system.
>> Although bug6889007.java fail with small test group with "Wrong cursor type"
>> error, it could not reproduce bug6884066.java
>> The hang issue might be due to waitForIdle() being called in loop which will
>> be calling sync() so replaced with delay..
>>
>> Modified fix passed the suggested small test group `desktop_timeout `
>> several times in all platforms
>> in addition to several iterations of the test run in standalone mode in all
>> platforms..
>
> test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 72:
>
>> 70: frame.pack();
>> 71: frame.setLocationRelativeTo(null);
>> 72: frame.setAlwaysOnTop(true);
>
> Why do we need to keep the window on top?
In windows primarily, I see sometimes the frame is rendered below some if there
are other windows present ie remains hidden and mouse cursor is moved which
looks odd, so I ensured the frame is always on top for the test
> test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 87:
>
>> 85: for(int i = -shift; i < width + 2*shift; i++) {
>> 86: robot.mouseMove(x++, y);
>> 87: robot.delay(100);
>
> It looks like we don't need this delay since there is
> `robot.setAutoDelay(100);` on line 56. A total delay of 200ms seems too much
> to me.
I dont think it's too much as compared to 500ms we have in some tests..Since I
have tested in all platforms with this values without any problems observed, I
will like to keep this value for now..
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198855883
PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198855919
