Pop-up menus and XGrabKeyboard/XGrabPointer

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?)?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]