xmonad grabs keyboard and mouse on focus follows mouse, reproducibly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start xmonad on my new lenovo yoga 11s laptop with provided xmonad.hs
2. use laptop for a few hours (I was seeing this at least twice a day)

What is the expected output? What do you see instead?

This seems to occur when moving the mouse with focus follows mouse, and 
switching focus from one terminal to another (I have seen it using both 
xfce4-terminal and the sakura terminal). Xmonad seems to grab all keyboard and 
mouse events, and not release them, which results in no mouse movements, 
clicks, or keyboard activity doing anything in either xmonad or the 
applications on screen.

However, ctrl-alt-FN works, and if I use the console to kill all my terminals, 
this seems to convince xmonad to stop grabbing inputs. 

I also tried using the console to start xev, and confirmed that it generally 
saw no X events at all. I think that one time xev reported a stream of X 
events, as if it were getting all the traffic I had generated while trying to 
use my locked desktop.

Also, at least twice, after a several minute delay xmonad has woken up on its 
own and dropped the grab. It then seemed to process all the keys I had pressed, 
which was disconcerting.

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

0.11 on Debian unstable with XFCE panel 4.10.1

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

It's attached. Note that I have used xmonad for years without seeing this 
problem. I switched laptops, made some minor changes to my xmonad.hs and now it 
happens frequently enough to be a real productivity problem. On the other hand, 
if someone is looking to debug this somehow, I can probably reproduce it 
reliably enough to try whatever steps make sense to debug it.

Original issue reported on code.google.com by joeyhe...@gmail.com on 8 Sep 2013 at 11:17

Attachments:

• xmonad.hs

[GoogleCodeExporter]

I should mention that I usually do use unclutter -root -grab, but I turned it 
off as part of the process of narrowing down that xmonad was responsible for 
this problem.

Original comment by joeyhe...@gmail.com on 8 Sep 2013 at 11:21

[GoogleCodeExporter]

Enabled setxkbmap -option grab:break_actions, so I can press keys to break 
mouse and keyboard grabs. This does unfreeze the desktop, but it crashes 
xmonad. However, this seems to prove that the problem is xmonad somehow leaving 
them grabbed,

Original comment by joeyhe...@gmail.com on 9 Sep 2013 at 3:52

[GoogleCodeExporter]

The best workaround when this happens seems to be to switch to the console and 
run DISPLAY=:0.0 xmonad --restart. Clears it right up.

Original comment by joeyhe...@gmail.com on 9 Sep 2013 at 3:28

[GoogleCodeExporter]

I have found a way to reproduce this at will. My laptop has a touch screen. 
Simply touching a window that is not focused generally causes the hang. If not, 
touching a second window that is not focused will certianly cause the hang.

Note that I have seen this same behavior when the touch screen is disabled, and 
I am only changing focus using the mouse pad. Perhaps I have been seeing this 
bug to often on this laptop due to the mouse pad being extra large and/or more 
sensitive.

Original comment by joeyhe...@gmail.com on 12 Sep 2013 at 11:54

[GoogleCodeExporter]

I have a theory that the problem may be caused by the mouse pointer effectively 
warping into the middle of a window, without for example, passing over the 
border between windows and so out of the previously focused window. Possibly 
combined with a mouse click arriving the instant the pointer arrives at its new 
location.

Original comment by joeyhe...@gmail.com on 12 Sep 2013 at 11:57

[GoogleCodeExporter]

I can reproduce this using the default xmonad configuration. Just tapping the 
touch screen locks it up with 2 terminals opened.

Original comment by joeyhe...@gmail.com on 13 Sep 2013 at 12:24

[GoogleCodeExporter]

I have found a better workaround for this bug than restarting xmonad. Since the 
mouse can still be moved, just use it to select some text. Somehow, this causes 
xmonad to release the event grab.

Original comment by joeyhe...@gmail.com on 17 Sep 2013 at 5:20

[GoogleCodeExporter]

I have had a similar problem: When I select a text input in firefox or chrome, 
sometimes the keyboard becomes unresponsive, even to C-M-fn. The mouse still 
responds and I can do stuff, but not fix the keyboard, even by deselecting or 
closing the relevant tab. I never had a spontaneous ungrab, even after leaving 
the laptop for some time.

I never had this problem until I upgraded from ubuntu 12.10 to 13.04. I was 
using xmonad 0.11. I now use i3 so this is no longer my problem. 

Original comment by dradet...@gmail.com on 24 Sep 2013 at 7:32

[GoogleCodeExporter]

I reported this bug when I'd just switched to a new laptop. I noticed that over 
time, the frequency of the bug happening went down. I apparently was doing 
something when the hardware was new to me, that I stopped doing. Probably 
fat-fingering its clickpad in some way was causing it to occur early on. Also, 
using the touch screen it's easy to reproduce the bug, but you need a touch 
screen (and now I keep mine turned off!)

Today, I found another, perhaps better way to reproduce a similar problem. All 
I need is a single window open in the current workspace. I first press and hold 
the left Windows key (mod). Then I press and release the right Alt key (this 
should be identical to clicking mouse button 2, which my laptop does not allow 
doing in hardware.. I use xkbset to bind right Alt to mouse button 2). Then I 
release the left Windows key.

Unlike the problem initially described, this results in the mouse movement not 
getting grabbed. Otherwise the behavior is as described: No key presses or 
mouse clicks (or focus follows mouse) has any effect, until I restart xmonad.

For some reason, I can't reproduce that with the stock xmonad configuration. 
However,
I can reproduce it with the default mouseBindings setting. If I install a 
custom mouseBindings that leaves off the mod-button2 binding, that naturally 
avoids the problem. (However, clicking on the touch screen can still cause the 
problem in that configuration.)

BTW, I seem to see some flashing of the window border when this bug happens, as 
if the window lost and regained focus.

Original comment by joeyhe...@gmail.com on 18 Jan 2014 at 8:19