On Tue, 17 Dec 2024 20:46:54 GMT, Alisen Chung <ach...@openjdk.org> wrote:
>> Currently on macOS when mouseMove is given an offscreen coordinate to move >> the mouse to, mouseMove will physically clamp to the edge of the screen, but >> if you try to grab the mouse location immediately after by using >> MouseInfo.getPointerInfo().getLocation() you will get the value of the >> offscreen point. >> >> Windows and linux do this clamping and coordinate handling for us, but new >> distributions may not necessarily handle clamping the same way, so Robot >> should be checking for clamping rather than delegating it to native. >> >> This fix updates shared code to cache the screen bounds and adds a check to >> not exceed the bounds in mouseMove. The caching is done in the Robot >> constructor, so if the screen bounds changes the constructor must be called >> again to update to the new bounds. > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > fixed test to fail before fix and pass after fix test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 44: > 42: robot.delay(500); > 43: > 44: Point currLoc = MouseInfo.getPointerInfo().getLocation(); Not directly related to this change, `MouseInfo.getPointerInfo().getLocation()` throws NPE for a multi-monitor extended display setup on windows for an off-screen location. It returns valid PointerInfo only if the point falls within the bounds of any of the screen device , else it returns null. This may be the expected behavior of MouseInfo.getPointerInfo() but the javadoc is not clear about how off-screen coordinates are handled. For this test you can add a null check before calling .getLocation() for sanity (although multimonitor setup is not the case for CI runs) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1893303023
