JDK-5097801 : Spurious mouse events are triggered on multi-mon - virtual screen linux setup
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_9.0
  • CPU: x86
  • Submitted: 2004-09-07
  • Updated: 2006-10-04
  • Resolved: 2006-04-05
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.
JDK 6
6 b79Fixed
Related Reports
Relates :  
JDK-6190081 - Dragging a frame using Robot is not working properly on Multi-mon setup, Solaris + xinerama
Relates :  
JDK-6287244 - Linux/Solaris robot should be rewritten
Relates :  
JDK-5097723 - Robot is not usable with multi-screen setup having a virtual screen, on linux
Description
Platform: Linux RH 9
Config: Multi-Monitor - Virtual Screen setup using Xinerama
JDK: All releases. Reproducible with Tiger, Mantis

I am showing a frame with a button on the secondary screen in a virtual desktop env. (The bounds of the virtual desktop spans to 2 monitors and windows are draggable across monitors). I am moving the mouse using robot inside monitor1. Button has been set with WAIT cursor. The following behaviors are noticed:

1. Mouse Entered, Mouse Exited and Mouse Moved events are triggerd by button when the button is actually placed in Screen2 and mouse is moved in Screen1.
2. The cursor changes to WAIT cursor when the mouse moves in screen1. 

This is incorrect since the component is displayed in screen2 and mouse is moved inside screen1. The actual scenarios is as follows:

For example (not a real data, assuming just for the explanation sake) the width of primary and secondary monitors is 1000. The coords of screen1 is 0, 0, 1000, 768. The coords of secondary screen is 1000, 0, 2000, 768. I am showing the button at 1100, 400 to 1200, 500. I am moving the mouse exactly at the same location in screen1 which is 100,400 to 200, 500. The locations (with respect to each of the monitors) are almost same except the fact that they are on different screens. 

I have attached a sample test. Run the sample test on Linux with Xinerama. You would see a frame being displayed on the secondary screen. Click on the button 'WITH THE MOUSE'. Now robot will try to move the mouse cursor in screen1. Watch it carefully. If the cursor changes to WAIT cursor and if you see some mouse events on the console, the bug is reproduced.

This is not reproducible when you click the button through keyboard. So make sure you click the mouse on the button. Make sure there is nothing under the mouse pointer when it is moved by the robot. Any native app below the mouse would prevent this bug from being reproducible. This is not reproducible with Windows_XP with a similar virtual screen setup.

The same issue has been mentioned in one of the other bugs that I filed (5097723) but the developer has requested me to file this issue separately. 

-----------------------------------------------------------------------------
Run the testcase. Click the button. Robot will move the mouse and will stop at some point in screen1. Now manually backtrack the same path with the mouse, ie, move the mouse backwards on the same path. You would notice that the mouse would disappear from screen1 and eventually appears on screen2 when you move it to the same location in screen1 where comp is located on screen2.

###@###.### 2004-09-07
Comments
EVALUATION We should investigate the problem in mustang ###@###.### 2004-09-13 As with some other bugs, the source of the problems is Xtest and Xinerama extensions interaction. In this particular case: when robot moves the mouse in the screen1, X server sends wrong notifications, as if the mouse is in screen2. The bug can be reproduced only when the mouse is in the secondary screen when first calling to robot.mouseMove() - that is reflected in the description section by mentioning, that the bug is not reproduced if the button is pressed with a key. I have wrote the native test - see attached file - that demonstrates the problem. It shows a window on the secondary screen and then launches two processes, one is listening for X server events, and another is moving the mouse pointer with XTestFakeMotionEvent(). You may note that the mouse is moved in the primary screen, but notifications contains X and Y coordinates in the secondary screen. The test should be run on the dual-screen Xinerama-enabled system, primary screen is 0,0,1280,1024 and secondary one is 1280,0,2560,1024. In the console current coordinates of robot movings and corresponding server notifications, if any, are printed. Test compilation: gcc -lX11 -lXtst -L/usr/X11R6/lib -o native native.c Test run: ./native So I'm closing this bug as will not fix, and will file a separate RFE about rewriting all the Robot routines on Linux/Solaris. ###@###.### 2005-06-17 12:24:07 GMT RFE 6287244 is created as an umbrella for Xtest+Xinerama bugs. ###@###.### 2005-06-17 12:58:55 GMT
17-06-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
23-09-2004