JDK-8201364 : [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0,0)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8,9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2018-04-10
  • Updated: 2019-10-16
  • Resolved: 2018-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b17Fixed
Related Reports
Relates :  
JDK-8232433 - [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail
Relates :  
JDK-8203371 - [unix] Component.getLocation() gives inconsistent coordinate for a component at (0,0)
Description
Component.getLocation() gives y coordinate (0,23) for a component at (0,0) on Mac.
But once the component is relocated to (0,0) , then Component.getLocation() gives (0,0).

Steps to reproduce:
1.Run the attached RelocationTest.java
2. Enter NewX & NewY to some value (Eg. 50,50) and click change location
3. Enter NewX & NewY as (0,0) and click change location
4. Click on Display Location : you will see (0,23)
5. Again change to some other location and change back to (0,0)
6. Click on Display Location : you will see (0,0)
Comments
http://mail.openjdk.java.net/pipermail/awt-dev/2018-May/013960.html
16-05-2018
I agree that this is a bug. http://cr.openjdk.java.net/~serb/8201364/webrev.00/
24-04-2018
Sergey, I want a clear confirmation on whether you accept this as a bug in AWT. The bug description says that the frame is moved to (0,0) twice and getLocation() reports different value on the second attempt. To me that is a bug, whatever the correct return value is. The test should assume default setup and should therefore check for (0,23), that should be a separate bug.
16-04-2018
Hi Sergey, As per your 1st comment: "The test should not assume that the window will be placed in the coordinates which were passed to setBounds(), the test should use coordinates returned by getBounds(). ", considering this how would you suggest to test, cases where we want to check the relocation of a component. that is: change its location and then check that it has been relocated as expected.
13-04-2018
Got it, thank you for clarification.
12-04-2018
Hi Sergey, I understand that the location of component is (0,23) as the menubar with height 23 is present. But I want to point out that the value returned by Component.getLocation() / Component.getBounds() changes to (0,0) if we set the location of component to (0,0), while the coponent is at the same location (0,23) and the menubar is still showing. You can reproduce this as follows: 1. Run the attached RelocationTest.java 2. Set new x,y as 0,0 3. Click on Display Location : you will see (0,0) while menubar is still there and component is at same location (0,23) I tried the same with Component.getBounds() and got the same result this inconsistency in the output is what led to the initial confusion
12-04-2018
Component.getLocation() returns correct coordinates (0,23) on macOS. 23 is a height of the menu bar. When the application tries to move the window to (0,0) the macOS itself will move the window to (0,23). I also tried to move the window using mouse. It is possible only if the menubar is configured to automatically hide/show(System preference->General->Automatically hide or show menu bar) The test should not assume that the window will be placed in the coordinates which were passed to setBounds(), the test should use coordinates returned by getBounds().
10-04-2018