JDK-8357584 : [XWayland] [OL10] Robot.mousePress() is delivered to wrong place
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: jfx24
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-05-22
  • Updated: 2025-06-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx25Unresolved
Related Reports
Relates :  
Relates :  
Description
It looks like the FX has the same issue as  JDK-8351907, so we may directly borrow a code from it.
Basically it uses Remote Desktop XDG portal to control mouse and keyboard

https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html


n our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.

This issue is related to the libEI support is now wired to the XTEST, and we have two parts of the issue:

1.

XTEST is now wired to libEI, it now asks for a user confirmation to allow interaction(see the attached confirmation.png), so we should now be able to click on native applications, window titles, etc.

However, our robot implementation is mostly uses XTEST, but there is an exception:
for mouse move we use XWarpPointer, which is not part of the XTEST, and it is not propagated outside of Xwayland server.

So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
on mouse press we call XTestFakeButtonEvent and it is handled by libei,
so the click happens where is the actual mouse cursor is in the system. That is why the test fails.

To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.

I did a quick test with the XTestFakeMotionEvent, and it works with the provided test, and it allows to click on the window title as well as expected.

I also attached a native reproducer to play with XWarpPointer vs XTestFakeMotionEvent behavior.



2.

The second part of this issue is the user confirmation itself:
It doesn't persist across reboots, it may timeout after a period of inactivity.

It still seems to conform the spec, but we will not be able to run automated tests in this case. 


Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1834 Date: 2025-06-18 15:33:45 +0000
18-06-2025

[~kcr] sure
09-06-2025

[~azvegint] I presume that when you port this to JavaFX you will also include the fix forJDK-8358452 to avoid the JNI exception pending issue?
09-06-2025