Bug 7627 - Copying non ASCII-from an Wayland application into session does not work
Summary: Copying non ASCII-from an Wayland application into session does not work
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.12.1
Assignee: Pierre Ossman
URL:
Keywords: relnotes
Depends on:
Blocks:
 
Reported: 2021-01-20 09:44 CET by Niko Lehto
Modified: 2021-01-21 13:46 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Niko Lehto cendio 2021-01-20 09:44:11 CET
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.
Comment 1 Pierre Ossman cendio 2021-01-20 10:54:51 CET
We're fixing other things with the clipboard right now, so let's see if we can fix this as well.
Comment 2 Pierre Ossman cendio 2021-01-20 11:08:54 CET
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
Comment 3 Pierre Ossman cendio 2021-01-20 11:19:17 CET
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.
Comment 4 Pierre Ossman cendio 2021-01-20 13:35:21 CET
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.
Comment 5 Pierre Ossman cendio 2021-01-20 16:00:14 CET
Reported upstream:

https://github.com/fltk/fltk/issues/182
Comment 7 Pierre Ossman cendio 2021-01-20 16:40:08 CET
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
Comment 9 Pierre Ossman cendio 2021-01-21 09:17:10 CET
Works well now. Tested on regular X11 and Wayland.
Comment 10 Linn cendio 2021-01-21 13:33:50 CET
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.

Note You need to log in before you can comment on or make changes to this bug.