On Wed, 9 Sep 2026 07:03:20 GMT, Jayathirth D V <[email protected]> wrote:
>> GetScreenLocTest is mainly checking whether getLocationOnScreen() picks >> proper information. >> >> With latest JDK code this test fails locally on macOS and windows, mostly >> because mouse event is not getting recognised because of decorated window. >> On local Oracle Linux VM, i can see that sometimes the smaller frame is not >> even shown and test fails. We need to make the windows undecorated and make >> sure things are rendered before we start selecting things on the frame. >> >> After making test more robust, it runs fine on all platforms. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Jayathirth D V has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains four commits: > > - Fix conflict in PL > - Use EDT for canvas > - Initial change > - Remove from PL I'm not sure if this is test issue. It seems the PR fixes it making the frame undecorated but it doesn't explain why decorated frame, which is the default, is not getting the correct frame location.. Also, it is mentioned "sometimes the smaller frame is not even shown" so making the frame undecorated will make it even smaller and will not be more visible The test never assumes a decoration size or compares Frame.getLocationOnScreen() to a requested frame location. Instead, it: 1. Gets the Canvas’s getLocationOnScreen(). 2. Uses Robot to click exactly there. 3. Requires the canvas to receive local mouse coordinates (0,0), then (1,1) the returned screen point must be the canvas’s actual top-left pixel. A decorated Frame is relevant because the canvas begins after the frame’s native left/top borders and title bar; the returned screen coordinate must include those offsets. I guess the problem is in platform's heavyweight-peer coordinate conversion. Maybe in windows, we need to correct `AwtComponent::_GetLocationOnScreen` in `awt_Component.cpp`, reached through `WComponentPeer.getLocationOnScreen(`). It should convert (0, 0) from the actual component HWND’s client coordinate system to screen coordinates—for example, with` ClientToScreen(componentHwnd, ...)`—rather than deriving the point from the decorated top-level Frame bounds. Similarly, for other platforms.. The point that test fails in HiDPI also suggest screen coordinate conversion is not correct probably. Also, it is mentioned in JBS > "This is not a bug in a test - the test is correct. The test passes on CDE, > IceWm, WindowMaker, sometimes on Gnome. > .... > mouse event arrives on native level with WRONG coordinates - when we press > point which is (0, 0) in component coordinate space we get (1, 1). ------------- PR Comment: https://git.openjdk.org/jdk/pull/32764#issuecomment-5601501977
