wayland: Multiline copy-paste contains CRLF line endings

Downstream bugs in Firefox, but from what I can tell, other GTK apps also have this behavior.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1547595
• https://bugzilla.mozilla.org/show_bug.cgi?id=1572104
• https://github.com/neovim/neovim/issues/10223

I think it's possible that this only happens on non-GNOME compositors, GTK/GNOME could have some internal workaround. The report comes from KDE and I'm using Sway (so wlroots).

Reproduction

Version information:

• Arch Linux 5.4
• wayland via sway

Steps:

• Open firefox with MOZ_ENABLE_WAYLAND=1.
• Then copy any text with line endings.
• Paste it in alacritty or any non-GTK program (I use wl-paste | hexdump -C and look for 0A which is \r).

I've confirmed that:

• It doesn't happen if I copy and paste inside GTK (I copied in firefox, created a new gist with the text contents, then pulled the file).
• It doesn't happen in Xwayland if I start firefox without the above flag. _ I wasn't able to confirm if this also happens on X11 because I run sway which is wayland-only

Analysis

I've traced out the issue a bit. On paste, firefox calls gtk_selection_data_set_text with proper line endings \n:

• https://hg.mozilla.org/mozilla-central/file/61ec58edfd13861591d5cd4b6387de92b35f23e3/widget/gtk/nsClipboard.cpp#l520

I've confirmed that GTK calls the gtk_selection_set_text_plain branch:

• https://gitlab.gnome.org/GNOME/gtk/blob/88da95d921f902ee3599ac39b26553a7c4eeb2fa/gtk/gtkselection.c#L683

GTK for some reason normalizes the line endings to CRLF internally so when reading the raw clipboard data, CRLF will be present:

• https://gitlab.gnome.org/GNOME/gtk/blob/88da95d921f902ee3599ac39b26553a7c4eeb2fa/gtk/gtkselection.c#L555

I think in some code uses selection_get_text_plain which normalizes back to LF when reading.

• https://gitlab.gnome.org/GNOME/gtk/blob/88da95d921f902ee3599ac39b26553a7c4eeb2fa/gtk/gtkselection.c#L629

There's a whole bunch of code around normalization in gdkselection-x11:

• https://gitlab.gnome.org/GNOME/gtk/blob/88da95d921f902ee3599ac39b26553a7c4eeb2fa/gdk/x11/gdkselection-x11.c#L408

Some of that was copied into gdkselection-wayland, but that seems to mainly run on Xwayland which might explain why it doesn't break when firefox is ran via Xwayland.

• https://gitlab.gnome.org/GNOME/gtk/blob/88da95d921f902ee3599ac39b26553a7c4eeb2fa/gdk/wayland/gdkselection-wayland.c#L128

Fix

GTK should either stop doing the normalize_to_lf/normalize_to_crlf dance internally, or the gdkselection-wayland code needs expanding to fix paste for Wayland as well, not just Xwayland. I might be able to write a patch if you provide some guidance on what the correct solution is.