Bug 3030

Summary: Xnest keyboard state corrupt on FocusIn
Product: xorg Reporter: Joshua Neuheisel <jneuheisel>
Component: Server/DDX/XnestAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: erik.andren, mark, mharris, roland.mainz, rstrode
Version: 6.8.2   
Hardware: x86 (IA32)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
xnest-update-modifier-state.patch none

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:


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

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
applied, thanks!
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
Re-opening ...
Comment 6 Seb James 2005-10-16 02:54:33 UTC
(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
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:

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
Comment 10 Peter Hutterer 2012-06-13 17:31:03 UTC
Created attachment 63000 [details] [review]

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.