After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344059 - Ways to make global keybindings work during grabs
Ways to make global keybindings work during grabs
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: EWMH specification
trunk
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 151500 334935 338612 409111 547937 659603 (view as bug list)
Depends on: 135056
Blocks: 659609
 
 
Reported: 2006-06-06 19:57 UTC by Elijah Newren
Modified: 2020-11-06 20:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch adding retrying and sleep to mousegrabbing code (1.43 KB, patch)
2006-07-02 12:52 UTC, Hans de Goede
reviewed Details | Review

Description Elijah Newren 2006-06-06 19:57:45 UTC
Not sure whether to file this under EWMH specification or X extension (or even just mark this as WONTFIX).  Anyway, if an application grabs the mouse or the keyboard, then global keybindings don't work.  There are lots of bug reports about it (often NOTABUG'ed or WONTFIX'ed since this would be very hard to fix, though I'm going to start marking them as duplicates of this one), but there are perhaps some good reasons to allow it:

  Any grab -- Something like Ctrl-Alt-Delete for opening the system monitor and
    allowing hung apps (with stuck grabs) would be very nice.  Currently, users 
    are hosed and forced to reboot (unless they are advanced and know about
    virtual terminals or remotely logging in and can kill the offending app
    from the command line).
  Drag & drop -- Window switching (e.g. alt-tab) and workspace switching (e.g.
    Ctrl-Alt-Arrow) keybindings; while the window list and workspace switcher
    applets exist, many don't like using them for this
  Menus open -- Window/workspace switching (should simultaneously cancel the
    menu that is open, of course)
  Any grab -- Voluming changing keybindings ought to still work, as should
    eject, play, pause, moving to the next item in the playlist, etc.
  Any grab -- taking a screenshot (the timeout thing is a copout, IMO, and
    makes the job harder for bug reporters and documenters)

  Other actions to consider that probably should be independent of at least
  some grabs: brightness up/down, suspend-to-ram/disk, activate screensaver?

It may also be worthwhile to consider specialized cases (e.g. games that grab the mouse, but would be willing to relinquish the grab on an alt-tab press).
Comment 1 Elijah Newren 2006-06-06 19:58:16 UTC
*** Bug 151500 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2006-06-06 19:59:32 UTC
*** Bug 334935 has been marked as a duplicate of this bug. ***
Comment 3 Elijah Newren 2006-06-06 20:01:18 UTC
*** Bug 338612 has been marked as a duplicate of this bug. ***
Comment 4 Alejandro Andrés 2006-06-07 12:10:21 UTC
But it worked in 2.12, so maybe a regression freak should check that :p
Comment 5 Alexey Rusakov 2006-06-07 12:38:14 UTC
Really? I observe this since, well, GNOME 2.6 or even earlier. And, I believe, even Gtk+ 1.2 was prone to this.
Comment 6 Elijah Newren 2006-06-07 14:54:14 UTC
Alejandro: I'm assuming reading the duplicates that you're referring to the volume control.  It's possible it worked in an earlier version, but if so, it definitely had to be using a mechanism at a lower level than normal global keybindings (which sounds more like a hack to me...).  If so, and people want to use the old method, then it would just mean that your bug shouldn't have been a duplicate of this one.    This bug has always been present in all version of Gnome.
Comment 7 Hans de Goede 2006-06-07 15:08:22 UTC
Notice that in 151500 I present a workaround for the alt-tab case.

When all what an app has got grabbed is the mouse (which happens much more often the keyboard AFAIK) then all that needs to be done to make keybindings work is for the code triggered by the keybinding to be able to handle the fact that the mouse is already grabbed. So the code triggered must either not try to grab the mouse itself at all, or be able to handle a failure in grabbing the mouse.

With the latter being what I've proposed as patch for the alt-tab case. With the alttab patch fullscreen apps (which must grab the mouse when changing resolutuion with xf86vidmode, otherwise the viewport can scroll (GRRR)) can relinguish the mouse upon a focus leave event. I don't know if many fullscreen apps currently have this release the mouse on focus out behaviour, but I'm a contributer to both the SDL and allegro and plib gaming libraries and I would be happy to send a patch upstream to all 3 to add this behaviour. Being able to alt-tab away from a fullscreen app is really nice, and we can make this happen.
Comment 8 Elijah Newren 2006-06-10 03:41:45 UTC
Hans: As per Havoc's comments in bug 151500, I'm skeptical too.  I would not trust such a mechanism to be help more than it hurts unless there were some standard (as part of the EWMH) with some application-and-window-manager communication for Metacity to know when it would be okay to do something like that.  This bug is partially about getting some specification nailed out -- you'll note that I listed  games and such as one of the particular cases to remember to handle to make sure your request isn't overlooked.
Comment 9 Hans de Goede 2006-07-02 08:53:55 UTC
I just was reminded about this bug, by another unrelated bug for an unrelated piece of oss, which also involves mouse grabbing.

This has lead me todo some experimenting, because in my memory there was soemthing weird what happened when trying to alt-tab away from a fullscreen game like xmame. The conclusions of this experimenting are as follows:

When metacity tries to switch away from a fullscreen window the application gets the following events in quick succession:
-focus out
-focus in
*now metacity tries to grab the
 mouse and stops the switch if it
 fails, on success:                 
-focus out

So I've modified xmame to be deaf for focus in events which are received quickly after a focus out and that makes alt-tabbing away work, unfortunatly alt-tabbing back is broken, probably because that goes like this (from memory from a long long time ago):
-focus in
-focus out
-focus in

So the second focus in gets ignored (because its quickly after a focus out), leading to xmame not regrabbing the mouse.

Now with this knowledge I think I can create an ugly clutch for this all to work in xmame and port that to SDL and allegro, but that is going to be ugly.

Currently AFAIK xmame is alone in ungrabbing the mouse when a focus out is received, but that can be added cleanly to the others.

The problem is that the app gets:
1) focus out
2) focus in
3) focus out

In quick succession instead of just a focus out and metacity trying to grab the mouse between 2 and 3 when the app has regrabbed the mouse.

I think this is because XGrabKey causes 1) and 2) when a grabbed key gets pressed because technically when the grabbed key gets pressed it gets send elsewhere and thus the app has temporarily lost focus. I'm afraid there is nothing we can do about this, but if we could change things so that the apps gets just a single focus out event when alt-tab is pressed* would make things a lot better.

*followed by focus in if the user cycles back to the app
Comment 10 Hans de Goede 2006-07-02 12:52:57 UTC
Created attachment 68261 [details] [review]
Patch adding retrying and sleep to mousegrabbing code

After some more experimenting I believe I've found the real cause of the strange:
-focus out
-focus in
-focus out
sequence being send to an application when that application has the mouse grabbed and you try to alt-tab away and the alt-tabbing away succeeds. It turns out that even without the patch I've attached to bug 151500 the alt-tabbing sometimes succeeds and when it does succeed without the patch the application only receives a focus out event not the strange:
-focus out
-focus in
-focus out
Sequence it receives with that patch.

I believe the problem is that there is a race:
1)ALT-tab gets pressed
2)The X-server Grabs the keyboard on behalve of metacity (which has a passive 
  grab on this key combo).
3)The X-server sends a focus out to the application which has the mouse grabbed
4)and at the same time the key event to metacity
5)The application might release the mouse grab upon receival of the focus out.
  (Most games will / should as they don't grab the mouse for a short while like
   other users/applications, but they grab it constantly).
6)at the same time metacity receives the key event and tries to grab the mouse 
  to show the alt-tab dialog

Now notice that 5 and 6 happen at the same time, so if metacity runs first the mousegrab will fail and if the app runs first and then the xserver runs and process the mouseungrab and then metacity runs then things go ok.

So most of the time this fails. This can easily be fixed by metacity sleeping and retrying a couple of times, this might fix many other scenarios where an app has a short grab too.

The attached patch may very well not be perfect but is a proof of concept of this. It might be an idea to make the retry behaviour a function argument and only do it sometimes, then again it might be best to alwasy retry.
Comment 11 Hans de Goede 2006-07-02 12:58:53 UTC
I forgot one important thing with my last comment. I've tried and with this patch switching (alt-tab) away from xmame even if it has the mouse grabbed in either window or fullscreen mode works fine.

I believe that this really is part of the solution. With this in place apps and game libraries who grab the mouse can be though to reluingish it on focus loose (assuming they are willing to handle this condition).

I started looking into this bug again, because I got a bug report against gcompris which also grabs the mouse in fullscreen mode in combination with gnome-screensaver. It turns out that gnome-screensaver when it kicks in does do the retry thing for a mousegrab and does it endlessly, since gcompris doesnot release the mouse on focus out this causes a hang gnome-screensaver, which has taken over control of the X-server, so effectivly a hang GUI. This isn't really related but is meant to document the fact that theis whole mousegrab business isn't easy and that there are valid reasons to release the mouse on focus out for games like apps.

Comment 12 Havoc Pennington 2006-07-02 15:53:14 UTC
"Fixing" race conditions by adding sleeps is really not the first choice... it just makes them less likely, but usually there's still some weird case where they happen, whether it's remote displays or heavily loaded systems or whatever.

In this case I think it might be OK to make metacity handle alt+tab without a mouse grab, i.e. it'd have to record that it didn't get it, in order to not ungrab ... I don't _think_ this would cause too many issues.

There could be other fixes... should think about it a bit, how to rearrange how stuff works so this can be more robust.

btw, why is the grab needed - if it's impossible to click outside the window anyway? (I see why for the screensaver, but in that case alt+tab should not even work)


Comment 13 Hans de Goede 2006-07-02 17:29:16 UTC
(In reply to comment #12)
> btw, why is the grab needed - if it's impossible to click outside the window
> anyway? (I see why for the screensaver, but in that case alt+tab should not
> even work)
> 

There are 3 different scenarios here:
1) xmame is running in a window and the user wantsd to control the game
   with his mouse. In this case xmame allows to user to grab the mouse so that
   he cannot click outside the window accidently. In this case it would be nice
   for the user to be able to just alt-tab away without having to first ungrab
   the mouse. And as an added bonus when the user gives the focus back to xmame
   by clicking it, or by using alt-tab again xmame automaticly regrabs the mouse.
   With kwm and with metacity with the attached patch this all works as 
   advertised, and I believe this is how it should work from an end user pov
2) xmame is running fullscreen in this case you are right, as xmame fullscreen
   uses Xv to stretch the image and fills the whole desktop. However the code in
   the path is shared with scenario 1
3) gcompris (and many others) switch the resolution using xf86vidmode when going
   fullscreen, in this scenario the mouse must be grabbed and confined to the
   window (which does not fill the whole desktop, only the viewport) in order to
   stop the viewport from scrolling. Now if Xorg would have a way to set the
   viewport and lock it, then that would be GREAT, but it doesn't.

About the sleep always leaving room for a race. I agree, but in most scenarios things will just work with the sleep and it the other case we are no worse off then today. Combining the sleep with the allow alt-tab with a failed grab may be even better. But what will you do on a failed grab? Just move the the next window on the window list as proposed in my other patch (see bug 151500) if you do it that way you don't even need to remember if the grab succeeded or not. I think combining these 2 patches might be a good idea.

But that would go against your previous argument that we actually want alt-tab to fail for cases where the application doing the grab _really_ wants to keep the focus like drag and drop, popup menus etc.



Comment 14 Havoc Pennington 2006-07-02 22:21:16 UTC
I'd be a lot more comfortable with any temporary/unreliable hack patches if there were a long-term plan - even if the long-term plan requires EWMH or X server changes.

For example:
 - there could be a protocol for asking the xmame type apps to drop their grab
   (with a reliable race-free way to wait for them to do it)
 - there could be an X server feature allowing the WM or other "special" apps 
   to break grabs (may be pretty dangerous)
 
Comment 15 Octavio Alvarez Piza 2006-09-20 19:12:01 UTC
In the case of menus...

Please excuse if this turns out to be off topic, I don't get why are the keyboard and mouse grabbed while a menu is dropped, in the first place. Is the grab really needed in this case?

On menus, why not set just the focus to the menu window upon drop? After dropping a menu down, as soon as I raise another window, the menu should disappear. Not on focus, but on raise.
Comment 16 Elijah Newren 2006-09-20 21:14:54 UTC
Octavio: If you want to try to convince all application and toolkit authors to stop grabbing the mouse/keyboard when a menu is shown, go for it.  But that belongs elsewhere (this is a metacity bug report, not a toolkit/application bug report).

Possibly to save you some time...I believe the standard response of toolkit/application authors is that they grab to prevent the override-redirect window from staying up if the user e.g. switches workspaces, since that would look weird.  So, I think it's just another bug due to the fact that override-redirect windows are braindead design, but I'm not sure if there were other reasons too.  Anyway, ask a toolkit author for a more definitive answer.
Comment 17 Alexey Rusakov 2006-09-21 10:57:27 UTC
In addition to what Elijah said, there's another (I believe, easier to fix) part of the story. In Gtk+, keyboard is grabbed because Gtk+ can catch keystrokes and assign them to a certain menu item (there's an option for this, not sure if it's on by default).
Comment 18 Elijah Newren 2007-02-18 00:13:50 UTC
*** Bug 409111 has been marked as a duplicate of this bug. ***
Comment 19 Jan Niklas Hasse (Account disabled) 2007-05-28 14:25:43 UTC
what's about making any grab (e.g. volume control) possible during fullscreen games? Is there any chance that this is going to be fixed in the future?
Comment 20 Hans de Goede 2007-05-29 06:20:45 UTC
(In reply to comment #19)
> what's about making any grab (e.g. volume control) possible during fullscreen
> games? Is there any chance that this is going to be fixed in the future?
> 

That should work for apps which only grab the mouse (which is the only thing needed for fullscreen games, unless they use DGA). However many game toolkits also grab the keyboard.

Comment 21 Jan Niklas Hasse (Account disabled) 2007-05-29 18:17:22 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > what's about making any grab (e.g. volume control) possible during fullscreen
> > games? Is there any chance that this is going to be fixed in the future?
> > 
> 
> That should work for apps which only grab the mouse (which is the only thing
> needed for fullscreen games, unless they use DGA). However many game toolkits
> also grab the keyboard.
> 

I've tried out, volume control works fine, and also my game can still get the keyboard input via XQueryKeymap.
But i can't leave full screen mode with ALT+TAB and if i press ALT+F4 the last active window is closed.
Comment 22 Harry Sufehmi 2010-04-12 01:04:40 UTC
Hi, I just found a way to ALT-TAB from Wolfenstein : Enemy Territory to the Gnome Desktop.
Here's how :

(1) Switch to Windowed Mode : pressing Alt-Enter usually works

(2) Activate the console : by pressing the ` (backtick? or tilda) key

(3) Now you can press ALT-TAB to your Gnome Desktop

I don't know why, but my guess is activating the console also releases its grab on mouse & keyboard. So then you can ALT-TAB to your desktop.

Since Wolfenstein is based on Quake-engine; my guess is you can do this trick too on other games based on that engine.

Hope it helps someone.
Comment 23 Cosimo Cecchi 2011-09-20 15:40:39 UTC
*** Bug 547937 has been marked as a duplicate of this bug. ***
Comment 24 Shahar Or 2012-03-14 13:15:23 UTC
Pleaaaaase fiiixxxxxxx :)
Comment 25 trusktr 2012-12-26 01:48:41 UTC
*** Bug 659603 has been marked as a duplicate of this bug. ***
Comment 26 trusktr 2012-12-26 01:52:01 UTC
We're in Gnome 3 and this bug still exists. A fix would be very nice. It's impossible to take a screenshot of the whole screen including contextual menus (right click).

My workaround is to switch to a virtual terminal, then use the command line to take a screenshot of the terminal that is running X.
Comment 27 André Klapper 2020-11-06 20:06:31 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.