Strange clipboard carriage return behavior

[ForLoveOfCats]

To be honest I'm not even sure what to title this one. I am on master (875ad40) and the GTK backend. The strange behaviour is that any carriage return which is placed into the clipboard by a druid app is either stripped or converted to a line feed but not really. Placing "\r\n" into the clipboard will result in druid only being able to retrieve "\n" from the clipboard afterwards but other applications can retrieve the expected "\r\n". Placing "\r" in the clipboard results in druid retrieving a "\n" and other applications retrieving "\r\n". Similarly placing "\rtext" into the clipboard results in druid retrieving "\ntext" but other applications retrieving "\r\ntext". Finally copying "\r\n" from a separate application (VSCode in this case) will allow druid to retrieve the expected "\r\n".

I've looked at the GTK shell implementation of put_string and get_string and they seem dead simple which causes me to think that it might be an upstream issue with either gtk-rs or GTK itself. I'm not sure yet but I wanted to open this so other backends could be checked as a sanity check and anyone who might know something pertinent might be able to share.

Here is an example program which reproduces the issue: https://gist.github.com/ForLoveOfCats/c037b8a901cdbfbfb0f7700a99887cfe

[ForLoveOfCats]

I'm adding the GTK shell tag for now, if the issue can be reproduced on a different shell then it can be removed

[cmyr]

hmm, nothing immediately comes to mind as a culprit, but it's possible we're being naive about line endings somewhere?

[luleyleo]

Well, I've been playing around with this and I get the same behavior with a GTK app written in Vala.
So it is at least not a problem with the GTK Rust bindings or druids internal handling.
Either GTK is doing something odd, or we are missing some magic sauce to make the clipboard work as expected.

[emigr2k1]

It seems GTK normalizes to CRLF when it sets the clipboard string and normalizes to LF when it gets the clipboard string. Check this comment and also this in GTK repo.

You can see the clipboard string with xclip -o -selection clipboard -t UTF8_STRING | hexdump -C

I believe this was changed in GTK4 but I haven't had the chance to play with it.

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1547595

[cmyr]

@emi2k01 thanks, that's helpful. Per this comment, I believe we're using get_data instead of get_text: https://bugzilla.mozilla.org/show_bug.cgi?id=1547595#c7