<AWT Dev> [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0)

[Dmitry Markov]

Hi Sergey,

According to your fix replacSurfaceData() and updateMinimumSize() are invoked only if the graphics device has been changed or the peer has been resized:

>  734         if (pResized || isNewDevice) {
>  735             replaceSurfaceData();
>  736             updateMinimumSize();
>  737         }

Shall we also check tResized in the statement above, (i.e. take into account changes in the target's size)?

Thanks,
Dmitry


> On 16 May 2018, at 19:23, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for jdk11.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201364
> Webrev: http://cr.openjdk.java.net/~serb/8201364/webrev.00
> 
> Description:
> The bug occurs when the application tries to set location of the window to the point, where the window cannot be placed. For example if this is a place where menubar, dock, taskbar etc are located.
> 
> We have a bug in our logic which updates the state of the component when the native window is moved. Usually we have these steps:
> 1 The app set bounds for window to (100,100).
> 2 The native window is moved to 100,100 or to any other location like 90,90
> 3 We get a notification from native and update the state of the peer to (100,100/90,90) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1)
> 
> When the bug is reproduced we have this steps:
> 1 The app set bounds for window to (0,0).
> 2 The native window is moved to 20,20, because 0,0 is a place for menubar.
> 3 We get a notification from native and update the state of the peer to (20,20) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1)
> 4 The app set bounds for the window to (0,0) again.
> 5 The native window is NOT moved, but still located at 20,20.
> 6 Our code assume that the native window was not moved and because of that we do not update the bounds in the component(which were set at step 4)
> 
> Note that this fix is for macOS, but the same bug exists on linux/solaris as well. I'll create a separate bug and will add it to the problem list in this fix.
> 
> 
> -- 
> Best regards, Sergey.