Pop-up menus and XGrabKeyboard/XGrabPointer
- From: Anders Kaseorg <andersk MIT EDU>
- To: gtk-devel-list gnome org
- Subject: Pop-up menus and XGrabKeyboard/XGrabPointer
- Date: Tue, 22 Jun 2010 15:56:28 -0400 (EDT)
Currently when GTK+ creates a pop-up menu, it uses XGrabKeyboard and
XGrabPointer to grab the keyboard and mouse. This has at least three
unfortunate side effects.
1. Global shortcut keys such as PrtSc and volume keys don’t work while a
menu is open. This has led to a flurry of bug reports against
gnome-screenshot and gnome-volume-control.
2. If an application hangs with a grab active (say because it’s running
over X forwarding and the connection is flaky, or because it’s nm-applet
and it ran off to make blocking DBUS calls to populate the menu, or
whatever), the entire desktop becomes unresponsive.
3. The screensaver can’t lock while a grab is active. This is a security
problem. Normally a few minutes of inactivity causes the screen to be
locked, but not if a menu is open. Worse, closing a laptop’s lid normally
locks the screen and suspends the computer, so that when it is opened
again, a password is required to unlock it; but if a menu is open while
the lid is closed, the computer comes up unlocked for whoever opens it
There are a number of open and WONTFIX bugs about this problem, spanning
more than seven years:
and several dozen duplicates.
My current understanding is that GTK+ grabs the keyboard to capture
accelerator shortcut keys, and the mouse so it knows to close the menu if
the user clicks outside of it. I don’t quite see why normal KeyPress and
FocusOut events aren’t sufficient for these purposes. But maybe there are
more complicated issues at play.
On #349037 I was advised to start a mailing list thread rather than
commenting on WONTFIX bugs, so here I am. How hard will it be to properly
solve this problem, and who else needs to be involved in the solution
(Xorg, other toolkits, applications?)?
] [Thread Prev