|Summary:||Xnest keyboard state corrupt on FocusIn|
|Product:||xorg||Reporter:||Joshua Neuheisel <jneuheisel>|
|Component:||Server/DDX/Xnest||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||high||CC:||erik.andren, mark, mharris, roland.mainz, rstrode|
|i915 platform:||i915 features:|
Description Joshua Neuheisel 2005-04-14 06:13:12 UTC
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.
Comment 1 Mark McLoughlin 2005-06-16 07:02:47 UTC
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.
Comment 2 Mark McLoughlin 2005-06-16 07:03:40 UTC
Created attachment 2897 [details] [review] Patch to fix multi-line macros in the manpage.
Comment 3 Adam Jackson 2005-06-25 14:29:11 UTC
Comment 4 Mark McLoughlin 2005-07-11 22:19:00 UTC
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.
Comment 5 Mark McLoughlin 2005-07-11 22:19:35 UTC
Comment 6 Seb James 2005-10-16 02:54:33 UTC
(In reply to comment #2) > Created an attachment (id=2897)  > 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
Comment 7 Mark McLoughlin 2005-10-16 23:12:43 UTC
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
Comment 8 Seb James 2005-12-01 04:16:12 UTC
Many thanks for re-posting that patch. I applied it to my 6.8.1 Xorg tree and it fixed the problem.
Comment 9 Erik Andren 2006-04-23 06:17:33 UTC
bugfix patch has been commited to trunk. Closing
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.