GNOME Bugzilla – Bug 734670
Different behaviour of gdk_selection_property_get between win32 and x11
Last modified: 2018-04-14 23:58:28 UTC
Created attachment 283203 [details] [review] win32: Fix GtkSelectionData::length for CF_UNICODETEXT data On X11, when receiving a UTF8 string from the clipboard using gtk_clipboard_request_contents(), GtkSelectionData::length will not take into account the final '\0'. gdk_selection_property_get() in gdkselection-x11.c does: /* Add on an extra byte to handle null termination. X guarantees that t will be 1 longer than nitems and null terminated */ length += 1; and then return length - 1; On Windows, GtkSelectionData::length will also count the final '\0'. gdk_selection_convert() in gdkselection-win32.c does: selection_property_store (requestor, _utf8_string, 8, data, strlen (data) + 1); This small difference is causing issues with spice-gtk/spice-vdagent. When remote-viewer (which uses gtk+) is running on Windows, text clipboard data length will include the '\0'. We then forward this clipboard data to the guest OS. If this OS is a linux guest, some applications get confused when we send them clipboard data containing a \0 and paste an extra unwanted NUL character. This can easily be worked around in applications (we can add an explicit strlen() call rather than relying on the size stored in GtkSelectionData, but it's also possible to change gtk+ on Windows to not take into account the NUL char when reporting the length of the clipboard data
Review of attachment 283203 [details] [review]: I wonder if this is some Windows specific kludge for utf8 clipboard that must be 0 terminated? (it might be hard to verify, since utf16 is the standard on windows) There is also a similar +1 there: dropfiles_prop->length = strlen (data) + 1; dropfiles_prop->format = 8; dropfiles_prop->type = _text_uri_list;
Review of attachment 283203 [details] [review]: I don't know if Windows can handle UTF8 clipboard, nor if gtk+ tries to feed UTF8 data into the windows clipboard on Windows (I couldn't figure out which function does that from a quick pass on the code ;) I've noticed the other similar +1 but as the method name (gdk_dropfiles_store) seems to imply it's in the drag and drop code, so I chose to leave this alone.
(In reply to comment #2) > Review of attachment 283203 [details] [review]: > > I don't know if Windows can handle UTF8 clipboard, nor if gtk+ tries to feed > UTF8 data into the windows clipboard on Windows (I couldn't figure out which > function does that from a quick pass on the code ;) It's not that windows can't, it can support any format. But it is more what applications are used to (I suppose gtk+ get utf8 data by preference for ex). It would be worth to try with some widespread utf8 editor on windows (excluding gedit) > I've noticed the other similar +1 but as the method name (gdk_dropfiles_store) > seems to imply it's in the drag and drop code, so I chose to leave this alone. ok, but the reason is probably the same, so it worries me to have two different handling
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
The code this changes was removed in 8caba9536cdccb6657b315c3af852b5febf712fb , no idea if it still has the same problem or not.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new