On Mon, 26 Aug 2024 19:02:56 GMT, Alexander Zvegintsev <azveg...@openjdk.org> wrote:
> There are two mouse pointer locations on Wayland: > > `#1` Wayland compositor - can be controlled by a physical mouse device, or > libei, this location is visible on a screen as a mouse cursor and is > propagated to `#2`. > > `#2` Inside the XWayland server - most of the time this is the same as `#1`, > unless we have changed it programmatically, e.g. by using the XTest extension > protocol, but it does not move the visible mouse cursor in `#1`. > Our tests in X11 compatibility mode using this approach(aka > `java.awt.Robot#mouseMove`) > > This test moves the mouse cursor to a specific location over a window in > `#2`, which most likely isn't the same as the visible cursor location in `#1`. > If the window was moved/resized and placed under the visible cursor location, > that cursor location is also set for `#2`, and from the test's perspective, > the mouse has just been moved to a different location without the test > expecting it, causing unexpected mouse enter/exit events. > > We can try to smooth this out with additional `robot.mouseMove` calls, but it > looks like we are missing the point of the test. > So for now it is better to skip the test on Wayland. > > Another way is to use libei to move the visible mouse cursor on the system > ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support > is not yet widespread on supported systems. > > Testing looks good. @azvegint There are a couple of cases (1st six cases in the test) that pass on Wayland. Would it be better to run only these cases on Wayland or is skipping the entire test a better option? ------------- PR Review: https://git.openjdk.org/jdk/pull/20717#pullrequestreview-2261689157
