On Tue, 17 Dec 2024 01:01:55 GMT, Alisen Chung <[email protected]> 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.
src/java.desktop/share/classes/java/awt/Robot.java line 223:
> 221: */
> 222: public synchronized void mouseMove(int x, int y) {
> 223: // peer.mouseMove(x, y);
Commented line can be removed.
src/java.desktop/share/classes/java/awt/Robot.java line 226:
> 224: peer.mouseMove(Math.min(Math.max(x, screenBounds.x),
> screenBounds.x + screenBounds.width),
> 225: Math.min(Math.max(y, screenBounds.y), screenBounds.y +
> screenBounds.height));
> 226: afterEvent();
@alisenchung It might be good to add a simple test case. Probably
robot.mouseMove() to off-screen coordinates and pass the test if the
coordinates returned by MouseInfo.getPointerInfo().getLocation() is clamped
(limited to screen bounds) else fail.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1887779880
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1887784313
