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

[Sergey Bylokhov]

On Fri, 20 Dec 2024 13:56:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Robot is already created with a screen .. ie GraphicsDevice .. the bounds are from that .. and it is already used elsewhere in Robot
>> If that can be across physical screens it will still work.
>> If screens are separate then Robot is constrained to that anyway.
>> 
>> Can you show a specific case where this is a problem ?
>
> I agree with Alex. Currently, it's possible to use a Robot instance to move mouse across all the screens in a multi-monitor environment.
> 
> According to the specification of [`Robot(GraphicsDevice screen)`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/Robot.html#%3Cinit%3E(java.awt.GraphicsDevice)), <q cite="https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/Robot.html#%3Cinit%3E(java.awt.GraphicsDevice)">Coordinates passed to `Robot` method calls like `mouseMove`, `getPixelColor` and `createScreenCapture` will be interpreted as being in the same coordinate system as the specified screen.</q>
> 
> I understand this statement correctly, it means that if I create a Robot instance with a screen that's not the main one, `Robot.mouse(0, 0)` should move the mouse to `(screenBounds.x, screenBounds.y)`.
> 
> However, if “share the same coordinate system to form a combined virtual screen”, `Robot` is expected to move mouse within the bounds of the virtual screen, isn't it?

Notes:
* The main screen does not necessarily starts from {0, 0}
* The robot.screen property only matter if the system is configured to use separate monitors (separate coordinate systems) - for example, when xinerama is disabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1907840970