Copying non-ASCII characters from an Wayland application into a session results in the unicode code point of the character being pasted. For an example, copying 'åäö' results in '\u00e5\u00e4\u00f6' being pasted. The ThinLinc server/client version used does not seem to matter. I could reproduce this issue by combining any of the following versions: Server - Nightly - 4.11.0 - 4.12.0 Client - Nightly - 4.11.0 - 4.12.0 This seems to not be the case on all desktop environments though: +--------------+---------------+---------+ | OS | Gnome version | State | +--------------+---------------+---------+ | Fedora 31 | 3.34.8 | Broken | +--------------+---------------+---------+ | Fedora 32 | 3.36.8 | Broken | +--------------+---------------+---------+ | Ubuntu 20.04 | 3.36.3 | Broken | +--------------+---------------+---------+ | RHEL 8 | 3.32.2 | Works | +--------------+---------------+---------+ So there seems to be something broken between gnome 3.32.2 - 3.34.8.
We're fixing other things with the clipboard right now, so let's see if we can fix this as well.
It seems like the issue is the ordering or clipboard formats. On RHEL 8 I get this if I copy something from gedit: > $ wl-paste -l > GTK_TEXT_BUFFER_CONTENTS > application/x-gtk-text-buffer-rich-text > UTF8_STRING > COMPOUND_TEXT > TEXT > STRING > text/plain;charset=utf-8 > text/plain > SAVE_TARGETS But on Ubuntu 20.04 the same thing gives me: > $ wl-paste -l > text/plain > text/plain;charset=utf-8 > STRING > TEXT > COMPOUND_TEXT > UTF8_STRING > application/x-gtk-text-buffer-rich-text > GTK_TEXT_BUFFER_CONTENTS (the order is preserved for the X11 clipboard, checked using "xclip -o -selection clipboard -target TARGETS) And checking FLTK's clipboard code we can see that it picks the first format of the ones it likes, which incorrectly includes "text/plain": https://github.com/fltk/fltk/blob/f3bff256da99da8e45544d35614dca73d04415a7/src/Fl_x.cxx#L1469
One question is why this order has changed. Only the order for Wayland has changed. If running gedit in X11 mode I get the same (old) order on both RHEL 8 and Ubuntu 20.04. So this suggests it is the Wayland clipboard handling in GTK+ that has changed. For reference, the newest working GTK+ we've seen is gtk3-3.22.30-6.el8.x86_64, and the oldest broken is gtk3-3.24.13-2.fc31.x86_64.
I can also confirm that this is a general FLTK issue as I can see the same problem in fldiff that's included with Ubuntu.
Reported upstream: https://github.com/fltk/fltk/issues/182
Unfortunately I'm unable to figure out where this change comes from. I could not find any relevant changes in GTK+, and the code looks like everything should still be ordered the same way. My best guess right now is that it is mutter that rearranges things (that's where an application sends its list in the Wayland case) and it's a side effect of this big change: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/320
Works well now. Tested on regular X11 and Wayland.
Tested with client build 6724 on Fedora 32 and Ubuntu 20.04, and the issue seems to be fixed. I tried copying from both gedit and chromium in to ThinLinc, and it works as expected. Release notes look good.