ssanthosh243 / semicomplete

Automatically exported from code.google.com/p/semicomplete
0 stars 0 forks source link

Simulated clicks screw up X server input interface #81

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.  Simulate several thousands clicks on a window $WINDOW  (of Chrome) that is 
not the active window

   xdotool click --position $X $Y --window $WINDOW 1

2. At exactly the right time, click on another window / window border with the 
real mouse.

What is the expected output? 

The simulated clicks should be send to the background window, without affecting 
the foreground window and the real mouse

What do you see instead?

Often the background window is raised to the foreground

Frequently the window starts to move and becomes locked to the mouse. Like if 
you click on "Move" in the title bar context menu. But more sticky, since it 
often does not stop moving when you click again.

Sometimes the entire interface completely freezes! Neither mouse inputs nor key 
inputs are possible anymore.  The only way to fix it, is to kill and restart 
the X server! (Output still works fine, videos/clocks update; non X11 input 
still works, e.g. switching to console with ctrl+shift+f1 )

What version of the product are you using? On what operating system?

xdotool version 2.20110530.1

X.Org X Server 1.14.5
Release Date: 2013-12-12
[    82.660] X Protocol Version 11, Revision 0
[    82.660] Build Operating System: Linux 3.13.0-rc2-patser+ x86_64 Debian
[    82.660] Current Operating System: Linux hostname 3.12-1-amd64 #1 SMP 
Debian 3.12.6-2 (2013-12-29) x86_64

    This is xfwm4 version 4.10.1 (revision 3918e6b) for Xfce 4.10
    Released under the terms of the GNU General Public License.
    Compiled against GTK+-2.24.20, using GTK+-2.24.22.

Original issue reported on code.google.com by benib...@googlemail.com on 14 Jan 2014 at 9:03