IMdkit: Track window property offsets correctly

IMdkit: Track window property offsets correctly

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>

rhbz#1175595
BUG=https://code.google.com/p/ibus/issues/detail?id=1751
TEST=client/x11/ibus-x11

[fujiwara, 2014-12-10 04:46:44]

LGTM.

I asked:
> 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.

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).

[Peng, 2014-12-12 02:42:08]

On 2014/12/10 04:46:44, fujiwara wrote:
> LGTM.
> 
> I asked:
> > 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.
> 
> 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).

LGTM

[fujiwara, 2014-12-18 07:22:33]

https://bugzilla.redhat.com/show_bug.cgi?id=1175595 is also reported and the
user confirmed this patch fixes the problem.

[fujiwara, 2015-01-06 06:49:14]

WRT your question, as to why XGetWindowProperty removes data when
bytes_after_return is zero and delete is set, this is actually documented in the
man page of XGetWindowProperty():

 | If delete is True and bytes_after_return is zero, XGetWindowProp-
 | erty deletes the property from the window and generates a Proper-
 | tyNotify event on the window.

Properties are stored in the Server, not in the clients, therefore the code that
actually removes the property is not to be found in libX11 but in the Xserver
itself, in ProcGetProperty() from dix/property.c:

http://opengrok.brq.redhat.com/source/xref/RHEL-6/xorg-x11-server/1.15.0/22.e...