Find X.org pointer grab owner
You can do this by pressing the XF86LogGrabInfo key, introduced in this commit.
By default, this keysym is not bound to any physical key or key combination. But you can still activate it using xdotool
:
xdotool key "XF86LogGrabInfo"
After executing that command, a list of active grabs will be logged to the X log. On Ubuntu at least, this is /var/log/Xorg.0.log
. It will be somewhere near the end of the log file, but there may be several irrelevant log messages below it. If there are no grabs, it writes:
[1199271.146] (II) Printing all currently active device grabs:
[1199271.146] (II) End list of active device grabs
If there are grabs (here, I opened a menu in Firefox), it logs something like:
[1199428.782] (II) Printing all currently active device grabs:
[1199428.782] Active grab 0x4c00000 (core) on device 'Virtual core pointer' (2):
[1199428.782] client pid 15620 /usr/lib/firefox/firefox
[1199428.782] at 1199423728 (from active grab) (device thawed, state 1)
[1199428.782] core event mask 0x7c
[1199428.782] owner-events true, kb 1 ptr 1, confine 0, cursor 0x0
[1199428.782] (II) End list of active device grabs
I've just had a similar issue, and narrowed it down to a a bug that somehow makes X11 think the middle button is pressed and not released. Physically disconnecting the mouse doesn't help, until there is a mouseup event.
The issue can be reproduced using xdotool mousedown 2
- it is impossible to switch focus between windows,
xdotool key XF86LogGrabInfo
shows current focused process window, but when one kills it, another window receives focus and same scenario continues.
Workaround: issue xdotool mouseup 2
.
Update: middle button being pressed and not released is simply the least noticeable one, because most apps don't respond to it, and some mice don't have this button to try and click to see if issue goes away.