x11: Handle case where clipboard was reclaimed quickly

When the reply to a TARGETS request comes in, the clipboard may already
be reclaimed by the local app. Deal with that case (in an ugly way,
strictly speaking we should use a cancellable here).

This happens for example at startup when the initial TARGETS requests
have not been answered until after the main widow popped up. And if such
a window immediately claims the primary clipboard (like when the initial
focus is inside an entry), this race will happen.
This commit is contained in:
Benjamin Otte 2017-12-01 07:42:36 +01:00
parent 24c934f8c0
commit ead67a7c17

View File

@ -408,6 +408,15 @@ gdk_x11_clipboard_request_targets_finish (GObject *source_object,
g_object_unref (cb);
return;
}
else if (gdk_clipboard_is_local (GDK_CLIPBOARD (cb)))
{
/* FIXME: Use a cancellable for this request, so that we don't do he brittle
* is_local() check */
g_bytes_unref (bytes);
g_object_unref (stream);
g_object_unref (cb);
return;
}
print_atoms (cb,
"received targets",
@ -421,8 +430,10 @@ gdk_x11_clipboard_request_targets_finish (GObject *source_object,
GDK_NOTE(CLIPBOARD, char *s = gdk_content_formats_to_string (formats); g_printerr ("%s: got formats: %s\n", cb->selection, s); g_free (s));
/* union with previously loaded formats */
formats = gdk_content_formats_union (formats, gdk_clipboard_get_formats (GDK_CLIPBOARD (cb)));
gdk_clipboard_claim_remote (GDK_CLIPBOARD (cb), formats);
gdk_content_formats_unref (formats);
g_bytes_unref (bytes);
g_input_stream_read_bytes_async (stream,
gdk_x11_display_get_max_request_size (display),