libX11: Changes to 'master'

[Egbert Eich]

 modules/im/ximcp/imDefIc.c   |   27 +++++++++++++++++++++++++++
 modules/im/ximcp/imDefLkup.c |    4 +++-
 2 files changed, 30 insertions(+), 1 deletion(-)

New commits:
commit e7fd6f0eda57300df4d6b695b7064610ca5dec57
Author: Egbert Eich <eich at freedesktop.org>
Date:   Thu Jun 16 18:47:49 2011 +0200

    XIM: Fix sync problem on focus change.
    
    XSetICFocus() and XUnsetICFocus() are both asynchronous events.
    This is a pretty stupid idea: those functions may undo certain
    settings on the client side for which requests from the server
    may still be in the queue unprocessed. Thus things may be set
    in the wrong order ie instead of set -> unest it will be unset -> set.
    Moreover there is no way for either the client or the server to
    cause the event queue to be flushed - which is pretty bad as
    XIM is bidirectional.
    The scenario is as follows:
    Two ICs are created:
            ic1 = XCreateIC(im,
                XNInputStyle, XIMPreeditCallbacks | XIMStatusCallbacks,
                XNClientWindow, window,
                XNPreeditAttributes, preedit_attr,
                XNStatusAttributes, status_attr,
                NULL);
            ic2 = XCreateIC(im, XNInputStyle,
                           XIMPreeditNothing | XIMStatusNothing,
                           XNClientWindow, window, NULL);
    Then the focus is removed from ic2:
            XUnsetICFocus(ic2);
    If SCIM is used as the input server it will send a bunch of requests
    following an XCreateIC(). One of the requests registers a key release
    filter. XUnsetICFocus() unsets both key press and release filters.
    Since it is asynchronous, the input server requests to register key
    press and release filters may not have been processed, when XUnsetICFocus()
    is called. Since there is no explicite way for client programs to enforce
    the request queue to be flushed explicitely before an X[Set/Unset]ICFocus()
    call it would be safest to make those two calls synchronous in the sense
    that they ensure the request queue has been handled before they execute.
    The easiest way to do this from Xlib is thru a call to XGetICValues()
    which sends a request to the server and subsequently reads the queue
    from the server to the client. This will cause all outstanding requests
    in the queue to be read and handled.
    This is an ugly hack and this could be fixed directly in the client,
    however it seems to be easier to fix Xlib than to fix numerous clients.
    This problem arose since there is no well documented way how to handle
    and synchronize XIM requests and not all input servers send requests
    when an IC is created.
    This has been discussed extensively in:
     https://bugzilla.novell.com/show_bug.cgi?id=221326
    
    Signed-off-by: Egbert Eich <eich at freedesktop.org>

commit 26ec7d3821bc19debc73c8c3e42e6e33ef6f856e
Author: Egbert Eich <eich at freedesktop.org>
Date:   Thu Jun 16 17:28:39 2011 +0200

    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 at freedesktop.org>