<AWT Dev>  Review Request: 8232433 [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail
philip.race at oracle.com
Wed Nov 13 22:18:49 UTC 2019
It looks reasonable, but we can be surprised .. if you have run all
headful tests on macos that might signal a problem then +1 ...
On 10/18/19, 5:10 PM, Sergey Bylokhov wrote:
> 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.
More information about the awt-dev