RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v3]

[Harshitha Onkar]

On Tue, 17 Dec 2024 20:46:54 GMT, Alisen Chung <achung at 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