<AWT Dev> [14] Review Request: 8232433 [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail

[Sergey Bylokhov]

On 11/13/19 2:18 pm, Philip Race wrote:
> It looks reasonable, but we can be surprised .. if you have run all
> headful tests on macos that might signal a problem then +1 ...

Correct, no new issues were found.

> 
> -phil.
> 
> On 10/18/19, 5:10 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for JDK 14.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232433
>> Fix: http://cr.openjdk.java.net/~serb/8232433/webrev.01
>>
>> This test places the window in the corners of the screen and checks that Window.getLocation() and Window.getLocationOnScreen() return the same result.
>>
>> The result of these methods mismatches if the window is placed in a (0.0) point more than once(where the global menu is located) and the macOS automatically will move the window to the (0,23). In this case:
>>  - getLocationOnScreen() will return the correct value(0,23) which was set by the latest native callback when the window was placed at the (0,0) for the first time and macOS moved it to (0,23).
>>  - getLocation() will return (0,0) because this value was set by the user via setBounds and was never updated to the real data, because we did not get a native callback when we tried to set location to (0,0) on the second time but it was ignored.
>>
>> The problem is reproduced on macOS 10.15 and I am not sure that it is a bug because it looks reasonable to skip native callback about NSWindow moving if the user request some location and macOS ignore it and leave the window on the same place.
>>
>> The fix will call this callback manually if the new location was ignored, and this will cause to reset the bounds used by the Window.getLocation() back to the correct value.
>>


-- 
Best regards, Sergey.