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.
