Examples: Application shortcuts don't work: * open Terminal * open window menu (upper-left corner, Terminal icon) * press Ctrl+D (logout; doesn't work) * press Ctrl+Shift+Q (quit Terminal; doesn't work) Global shortcuts don't work: * same setup as before (Terminal, its window menu), add any other window in the background * press Ctrl+F1..F4 (switch to desktop 1..4; doesn't work) * press Alt+Tab (switch to the other window; doesn't work) Other popups that cause this behavior: * Xfce Menu * Firefox URL autocomplete/suggestion popup * Most applications File/Edit/Help/etc. menus. Exception: Firefox appears to auto-hide those as soon as I press Alt to switch windows Some global shortcuts that DO work: * Ctrl+Alt+F1..F6 (leave X and switch to #tty) * Ctrl+Alt+Bksp (kill X)
I doubt this is different with other window managers (metacity ea). The menu grabs the input to handle Alt+.. events.
Just because everyone else does it this way doesn't really mean it's the right way to do it. KDE, for instance, has a bug open for this.. since 2004.. for whatever reason it's not getting fixed. There are many incarnations of this bug, including hardware buttons (e.g. volume control buttons present on many laptops) and it can get very annoying at times. MS Windows deals with this the same way as I described Firefox File/etc. menus -- the popup closes immediately on Alt, so by the time Tab (or anything else) is hit, system catches it. Not necessarily THE way to do it, but it's a possibility.
This is a behaviour for the GTK menu implementation (Firefox does not use this which explains why it isn't affected), not related to Xfwm4 as Nick told.
The bug is still there, though - it's impossible to alt-tab out of a window or to use hardware volume control buttons if the window has the alt-menu open.
Right, this bug was closed because there is nothing we can do about it. The menu has an active grab on the pointer and keyboard, and the X protocol has no mechanism to /steal/ a grab from another application. Reopening this bug won't change the fact that we cannot fix it, so closing as wontfix instead, maybe it's more explicit...
Wouldn't it make more sense to write an upstream bug and make this one "depend" on it - at least so it could be tracked?
(In reply to comment #6) > Wouldn't it make more sense to write an upstream bug and make this one > "depend" on it - at least so it could be tracked? Upstream? We are upstream we are not a distribution (downstream vs. upstream). I guess you mean opening a bug with... with who is the the actual question... - Xorg? unlikely they're gonna change the X protocol at this point, also because the grab works just like expected - the toolkits? there are way so many of them, and adding a mechanism to notify the toolkits to release their actiuve grabs is a daunting task, unlikely to happen any day. This issue is not new and definitely not specific to Xfce, we (as a project) don't have the resources to overtake such things, and I (speaking for myself) don't have the will to change something that I reckon is the expected behavior. But please, feel free to take this to some other projects /upstream/ if you want. Just a last note, the Wayland protocol (last time I checked) did not have grabs so such problems would possibly be avoidable in Wayland. So all hope is not lost.