aboutsummaryrefslogtreecommitdiff
path: root/nxcomp/GenericReadBuffer.h
diff options
context:
space:
mode:
authorEgbert Eich <eich@freedesktop.org>2011-06-16 17:28:39 +0200
committerUlrich Sibiller <uli42@gmx.de>2016-10-19 21:40:28 +0200
commited53aca1d68a5d7511b1304f11a43ba80885fbe2 (patch)
treeb74a8bb80f7e0ebc60a86f91dd79a30985d98971 /nxcomp/GenericReadBuffer.h
parentadcf3894aa3663b1debba412a85104a5c17fc3bb (diff)
downloadnx-libs-ed53aca1d68a5d7511b1304f11a43ba80885fbe2.tar.gz
nx-libs-ed53aca1d68a5d7511b1304f11a43ba80885fbe2.tar.bz2
nx-libs-ed53aca1d68a5d7511b1304f11a43ba80885fbe2.zip
XIM: Fix race on focus change: set 'FABRICATED' only when keyev filters in place.
When synthesized key events are sent on commit XIM sets the 'fabricated' flag so that the keypress handler knows that these were not real events. This also happens when committing due to the loss of focus. However in this case the keypress/release filters which consume and unset this flag are no longer in the filter chain. So the flag is erronously set when a real keyboard event is received after focus has been regained. So the first event is wrongly treated as a fabricated key in the keypress handler which will at the same time reset the flag so the second key event is treated correctly. This fix only sets the flag when at least one of the keyboard filters is in place. How to reproduce this bug: run scim, choose a Japanese input method start two instances of xterm: start typing in one xterm (this should pop up an IM window). Without comitting (hitting 'enter') move focus to the other xterm, then move focus back. Start typing again. The first character will be committed immediately without popping up an input window. With this fix this behavior is gone. See also: https://bugzilla.novell.com/show_bug.cgi?id=239698 Signed-off-by: Egbert Eich <eich@freedesktop.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
Diffstat (limited to 'nxcomp/GenericReadBuffer.h')
0 files changed, 0 insertions, 0 deletions