The gdk_x11_atom_to_xatom_for_display() function, in gdk/x11/gdkproperty-x11.c, responds to the special input value GDK_NONE by generating an XInternAtom call for the string "NONE", which yields an X11 atom identifier not equal to the special value None.

The effects of this can be seen when requesting an unsupported selection target type from a GTK-using application. To demonstrate this most easily I need to refer to my own small utility 'xcopy', which has a verbose logging mode that shows up the problem.

If you download xcopy.tar.gz from http://www.chiark.greenend.org.uk/~sgtatham/utils/, you can demonstrate the bug by the following procedure:

 - Start up gnome-terminal.
 - Drag to select some text in it.
 - Run 'xcopy -v -r -a RECTANGLE'. (-v means verbose; -r means read the contents of the selection; -a RECTANGLE means to request a data type identified by the word RECTANGLE, which is not a data type supported by gnome-terminal.)

The log data output by xcopy will include a line of the form
got SelectionNotify: requestor=03400001 selection=PRIMARY target=RECTANGLE property=NONE
The field "property=NONE" is the key one. If you try exactly the same test with xterm, it will instead say
got SelectionNotify: requestor=03200001 selection=PRIMARY target=RECTANGLE property=None
"None" in title case is output by xcopy in response to the atom value in the SelectionNotify event being the special value None. In the case where it's talking to gdk, however, it instead outputs NONE in all-caps, and that's because it received a non-null atom value that expanded to the _string_ NONE. The upshot is that a program receiving such a notification may wrongly think that it has received some zero-length selection data, rather than that it has not received any data and should try a different format.

In particular, this caused me to have an actual practical problem with Evolution 2.12.3 talking to the Cygwin X server on Windows. Right-clicking a URL in Evolution and requesting "Copy Link Location" copies to the clipboard in only plain STRING format; if you then try to paste into a Windows window, the Cygwin X server's clipboard synchronisation module first requests the selection in COMPOUND_TEXT format - and gets one of these pseudo-NONE atoms in response, which inhibits it from falling back to a different format, so cut and paste fails.

From looking at the code, the problem seems to begin when gtkselection.c calls gdk_selection_send_notify_for_display with property set to GDK_NONE. gdk_selection_send_notify_for_display() fills in xevent.property by passing that value straight on to gdk_x11_atom_to_xatom_for_display. It should either check its input for GDK_NONE and avoid calling that function, or (I think more likely) gdk_x11_atom_to_xatom_for_display ought to check _its_ input for GDK_NONE so as to fix the same problem in any other situation where it might crop up.

I've just downloaded gtk+ from git and verified (by code inspection) that the problem still seems to be present in the most up-to-date revision as far as I can see. I attach a tiny patch by way of demonstration of the sort of fix that I think should work, though unfortunately I haven't been able to test it:

diff --git a/gdk/x11/gdkproperty-x11.c b/gdk/x11/gdkproperty-x11.c
index 36b8e9f..bf18674 100644
--- a/gdk/x11/gdkproperty-x11.c
+++ b/gdk/x11/gdkproperty-x11.c
@@ -190,6 +190,9 @@ gdk_x11_atom_to_xatom_for_display (GdkDisplay *display,

   g_return_val_if_fail (GDK_IS_DISPLAY (display), None);

+  if (atom == GDK_NONE)
+    return None;
+
   if (display->closed)
     return None;