From aabca2864d9439bc061feedd8d315b9aaac5c666 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 3 Oct 2010 21:45:45 +0200 Subject: spicec-x11: Force processing of ownerchange event when releasing the cb 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. --- client/x11/platform.cpp | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'client/x11/platform.cpp') diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp index ea2558d7..75b34c61 100644 --- a/client/x11/platform.cpp +++ b/client/x11/platform.cpp @@ -3342,5 +3342,18 @@ bool Platform::on_clipboard_request(uint32_t type) void Platform::on_clipboard_release() { + XEvent event; + XSetSelectionOwner(x_display, clipboard_prop, None, CurrentTime); + /* Make sure we process the XFixesSetSelectionOwnerNotify event caused + by this, so we don't end up changing the clipboard owner to none, after + it has already been re-owned because this event is still pending. */ + XSync(x_display, False); + while (XCheckTypedEvent(x_display, + XFixesSelectionNotify + xfixes_event_base, + &event)) + root_win_proc(event); + + /* Note no need to do a set_clipboard_owner(owner_none) here, as that is + already done by processing the XFixesSetSelectionOwnerNotify event. */ } -- cgit