On Thu, 17 Sep 2026 06:56:58 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 six commits: > > - Merge remote-tracking branch 'upstream/master' into 4753654 > - Merge remote-tracking branch 'upstream/master' into 4753654 > - Fix conflict in PL > - Use EDT for canvas > - Initial change > - Remove from PL I have debugged product code for all 3 platforms macOS, Windows and Linux. I have updated the test to use decorated frame only. Test fails on macOS because the when we move to exact (0,0) location in a decorated frame it is hitting macOS's native resize region and cursor actually changes to a resize cursor. Mouse press at this level are not forwarded as mouse event on Canvas to Java level. There are treated as non-client presses as shown at : https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m#L1026. Also the original intent of the test is to actually see whether getLocationOnScreen with mouse move hits proper position on component, so i have introduced insets. Now with insets and also a decorated frame, i can see mouse events are recognized properly as test runs reliably on macOS. Test fails only on specific display scaling locally on my Windows machine. I am seeing issue here because coordinates are getting rounded. https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L5589 gets the native canvas coordinates and rounds it to integer user space values. Robot again scales back these integer coordinates back to device pixels: https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java#L419. So at scaling factor like 1.5 these rounding of values makes the cursor to not move at exact (0,0) position of canvas and we don't get any mouse event. Locally on my Windows the test hits the wrong pixel only for 150% display scale and all other scaling works fine because for those scalings rounding of values is not resulting in change of pixel coordinates. I am making the test to run only on uiScale=1 to overcome this scenario. Again the original test is to check whether we can get proper location for a component and testing with fixed scaling suffices that requirement. I don't see the need for adding some margin for received mouse event coordinates check and run this test on any scaling factor. JBS bug comment from 2002 talks about Window manager not receiving the mouse event at (0,0) on Linux. But when i check without insets and decorated window on the latest code i don't see such issue. We receive the mouse event at (0,0) and test runs properly. I have added new logs and have made test more robust. This test is problemlisted on all platforms around 2018 when we started the CI testing. Test was not updated/changed from the time is was introduced in 2002. I don't see any product issue while running this test and with changes it runs fine on all platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32764#issuecomment-5728776229
