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

[Philip Race]

It looks reasonable, but we can be surprised .. if you have run all
headful tests on macos that might signal a problem then +1 ...

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