IMdkit: Track window property offsets correctly

[klemensbaum]

Problem symptoms

Input Methods relying on IMdkit for XIM support are susceptible to causing
hangs in X clients due to improper requests from the input method to the X server.

The following bug reports by users are related to this issue:

• https://www.libreoffice.org/bugzilla/show_bug.cgi?id=78081
• https://bugzilla.redhat.com/show_bug.cgi?id=452849#c19
• http://tracker.xemacs.org/XEmacs/its/issue565
• https://code.google.com/p/ibus/issues/detail?id=1751
• https://code.google.com/p/ibus/issues/detail?id=1697
• https://code.google.com/p/ibus/issues/detail?id=862
• http://lists.schmorp.de/pipermail/rxvt-unicode/2010q2/001176.html

Detailed description

The XIM specification requires that XIM tranports over 20 bytes in size
be transferred via window properties. The sender calls XChangeProperty
with PropModeAppend, and instructs the recipient via ClientMessage to
call XGetWindowProperty with delete set to True.

Naive implementations exhibit a race condition because the receiver
could have written more data in the meantime, and XGetWindowProperty
only deletes the property when bytes_after_return is zero. If
bytes_after_return is non-zero, it is necessary to use an offset when
reading from the property again.

To ensure that the property data does not grow indefinitely, Xlib
recycles 21 Atoms in round-robin fashion. Because the XIM specification
does not limit the number of Atom names of the form "_clientXXX" to be
used for data transfer over window properties, an XIM server should be
able to keep of track any number of Atoms, remembering the offset into
each property.

This patch implements correct tracking of property offsets.

Signed-off-by: Klemens Baum klemensbaum@gmail.com
Reviewed-by: Keith Packard keithp@keithp.com

[fujiwarat]

Thank you for the patch.
It seems your patch fixes a hang in rxvt-unicode of https://code.google.com/p/ibus/issues/detail?id=1751 .
But https://code.google.com/p/ibus/issues/detail?id=1697 is not fixed.
I uploaded a test program:
https://fujiwara.fedorapeople.org/ibus/20141128/preedit_position.c
The prblem is typing "Window" does not give the right order.

[klemensbaum]

I can reproduce the other bug with your test program, but it seems to be an issue with Xlib and would have to be fixed separately.

[fujiwarat]

OK, I see.

[klemensbaum]

Could you merge this pull request?

[fujiwarat]

Yes, we're reviewing the patch.

[fujiwarat]

I have a question.
The saving offset in_Xi18nSetPropertyOffset() does not depend on the value of bytes_after_ret from XGetWindowProperty() ?
In my test, bytes_after_ret is 88, 68, 44 and offset is 44. I.e. bytes_after_ret is sometimes greater than offset.

[klemensbaum]

The offset only indicates how much of the property's data has already been consumed. It does not depend on bytes_after_ret other than being reset to 0 when the property is deleted (i.e. bytes_after_ret is 0).

[fujiwarat]

Committed the patch.
Thank you.