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.
