Force processing of ownerchange event when releasing the clipboard
commit00263045206cb11b06a6e1fe7b0c734070b3fa33
authorHans de Goede <hdegoede@redhat.com>
Mon, 4 Oct 2010 11:38:15 +0000 (4 13:38 +0200)
committerHans de Goede <hdegoede@redhat.com>
Mon, 4 Oct 2010 11:38:15 +0000 (4 13:38 +0200)
tree01d6d8c4ea9af5885217ae0a89b5530ccda9cb96
parentc6320d183f7b477c8dca94f490b504588652d387
Force processing of ownerchange event when releasing the clipboard

Make sure we process the XFixesSetSelectionOwnerNotify event caused by
us setting the clipboard owner to none, directly after setting the owner
to none. Otherwise we may end up changing the clipboard owner to none, after
it has already been re-owned because the XFixesSetSelectionOwnerNotify event
to owner none is event is still pending when we set the new owner, and
then changes the owner back to none once processed messing up our clipboard
ownership state tracking.

I saw this happening when doing copy twice in succession inside the guest.

+ some other misc fixes (memory leak, unneeded XFlush)
99-vdagent.rules
vdagent-x11.c