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 > Previously, we used a different method, which might behave differently (It > also used a different thread): > [eea06f7#diff-698576e56937835cfc553bbd97fe12fabf954e0a20e7b9c3bfc3a77763fb6bd0L123](https://github.com/openjdk/jdk/commit/eea06f70fc6154be12d066df6669e7c6d8c0bc09#diff-698576e56937835cfc553bbd97fe12fabf954e0a20e7b9c3bfc3a77763fb6bd0L123) More on the above .. The fix you linked to was to "unify" getting mouse location. src/macosx/native/sun/awt/CCursorManager.m < [NSEvent mouseLocation] > CGEventRef event = CGEventCreate(NULL); > CGPoint globalPos = CGEventGetLocation(event); src/macosx/native/sun/awt/CRobot.m < CGEventRef event = CGEventCreate(NULL); < CGPoint globalPos = CGEventGetLocation(event); So what it did is delete the code in CRobot that did it and move it into CCursorManager. So CCursorManager now does EXACTLY what Robot used to do. And CCursorManager's old code using NSEvent superficially looked different but these really are the same underlying API https://developer.apple.com/documentation/appkit/nsevent/cgevent?language=objc Moreover, it looks like as part of the "unification" the fix dropped clamping code in Robot (!) https://cr.openjdk.org/%7Epchelko/9/8035568/webrev.02/src/macosx/native/sun/awt/CRobot.m.udiff.html So I guess we are fixing a regression caused by that fix, and perhaps more precisely to the bounds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2864275801
