This bug seems to have been around for a while, but I'm currently using version 6.8.2 of the source. When keyboard focus leaves an Xnest window due to a shortcut-key combination (such as "C-t C-t" in ratpoison or "Alt-tab" in gnome-session), and focus later returns, the windows running in the Xnest server window have the wrong keyboard state - namely they think the modifier key ("Ctrl" or "Alt" in the above examples) is still pressed. How to duplicate: 1. Start a gnome session (or ratpoison). 2. Open an Xnest window and spawn an xterm in it. 3. Switch focus from the Xnest window to a different window using a modifier-enhanced shortcut-key combination: Alt-Tab (or C-t C-t in ratpoison). 4. Refocus the Xnest window. 5. Any keys typed to the xterm will now have an "Alt" modifier. To fix the problem, press and release the "Alt" key (or Ctrl key if using ratpoison). It seems as though Xnest is not doing something correctly to check the new keyboard state when it gains focus.
This is pretty obvious when using Sabayon (http://www.gnome.org/projects/sabayon) - e.g. see this bug: http://bugzilla.gnome.org/show_bug.cgi?id=305806 In more detail, here's what's happening: 1) The window manager does XGrabKey() on Alt-Tab 2) User presses Alt 3) Xnest gets Alt KeyPress and updates modifier state 4) User presses and releases Tab 5) Active key grab kicks in, window manager switches focus, releases key grab 6) User releases Tab 7) Some other client gets the Tab KeyRelease 8) Xnest still considers Alt to be pressed There's lots of ways to reproduce the problem - e.g. hold down Alt while Xnest is focused, click on another window to switch focus ... Xnest never sees the Alt KeyRelease The fix is fairly straightforward - Xnest should just pay attention to the modifier state in the XEvents it gets. So, e.g. if it receives a key event and sees that Alt shouldn't be down (because the modifer state in an XEvent is zero) but it considers it to be down, then we should just generate an Alt KeyRelease before queueing the event. Attaching patch to do that.
Created attachment 2897 [details] [review] Patch to fix multi-line macros in the manpage.
applied, thanks!
Comment on attachment 2897 [details] [review] Patch to fix multi-line macros in the manpage. Nominating for the 6.8.x branch. Its a long-standing nasty bug with a fairly straightforward fix, so it seems like a good candidate.
Re-opening ...
(In reply to comment #2) > Created an attachment (id=2897) [edit] > xnest-update-modifier-state.patch > This attachment seems *not* to be the xnest-update-modifier-state.patch, but instead is this patch: 025f_XPutImage_manpage_macros_fix.diff Can the update-modifier patch be re-posted? I really need it. Many thanks, Seb James
It looks like all the attachment links got screwed up (same thing happened in bug #3664). Here's the real patch which went into HEAD: http://www.gnome.org/~markmc/code/xnest-update-modifier-state.patch
Many thanks for re-posting that patch. I applied it to my 6.8.1 Xorg tree and it fixed the problem.
bugfix patch has been commited to trunk. Closing
Created attachment 63000 [details] [review] xnest-update-modifier-state.patch attaching the bug to preserve for posterity.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.