On Tue, 17 Dec 2024 20:46:54 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 incrementally with one additional > commit since the last revision: > > fixed test to fail before fix and pass after fix I wonder if this is even a bug in `Robot`. The description says, <q cite="https://bugs.openjdk.org/browse/JDK-8345538#descriptionmodule";>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.</q> That is the OS didn't allow mouse cursor to move beyond the virtual screen bounds but `MouseInfo.getPointerInfo()` still reads the value that's outside of the screen. Is it expected that `MouseInfo.getPointerInfo()` is updated immediately? What does macOS API documentation say about passing mouseMove coordinates outside of the virtual screen? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2557087118
