On Wed, 30 Apr 2025 21:13:12 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 with a new target base due to a > merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538 > - move clamping code into macos > - use absolute distance to choose correct screen for offscreen clamping > - helper function > - grab screen data on mouseMove > - fix bounds > - peer.mouseMove > - fix implementation > - robot update > - Revert "robot multimonitor fix" > > This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9. > - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872 Sure I can create a reproducer and submit an issue to Apple, but is there any reason to not fix the clamping on our end as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2859214656
