#2175 No support for mime-based utf-8 targets

[Chris Graham]

On my system, Ubuntu 19.10, Xorg server, pasting into Scintilla from any closed application fails.

This is a fairly complex issue, so I'm including additional details so it's properly explained. A patch is attached (*1).

Scintilla puts its clipboard contents into the GTK clipboard manager on-the-fly (well, Gnome's clipboard manager that GTK talks to via the FreeDesktop spec), via setting the gtk_clipboard_set_can_store flag. It also saves via gtk_clipboard_store upon exit.

This is necessary because normal X11 clipboard management breaks once the owning application is closed. The clipboard manager works by having it, as a background application, become the clipboard owner.

Specifics of my set up that probably don't relate to the bug, but are interesting:
On my system, with the default Gnome clipboard management, gtk_clipboard_set_can_store does something and gtk_clipboard_set_can_store does nothing because gtk_clipboard_real_set_can_store (inside GTK) is returning false, because apparently it is not yet commonplace for clipboard managers to implement the complete FreeDesktop clipboard management specification [see: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/320, and I know the clipboard managers I installed didn't do it either].

Anyway, the clipboard all works fine, until the application the data came from is closed (*2). Once the application is closed, something in the system wipes out the UTF8_STRING target that was persisted into the X11 clipboard (via Gnome's clipboard manager) and leaves only "text/plain;charset=utf-8". My guess is this is some kind of optimisation step, but I don't know.

This is not a problem for most applications using the GTK clipboard API because they are using gtk_clipboard_request_text. gtk_clipboard_request_text is 'blocking', returning an immediate result - and it implements a chain of fallback targets (text/plain;charset=utf-8 at first, with fallbacks to UTF8_STRING, then COMPOUND_TEXT) until it gets that result.

Scintilla on the other hand calls gtk_clipboard_request_contents, with an explicit request for the UTF8_STRING target. Requesting an explicit target is implicit in use of gtk_clipboard_request_contents, as it will only callback once.

My patch implements a similar fallback to GTK's own gtk_clipboard_request_text, although with reversed order to not rock the boat too much with what Scintilla already does. It tries UTF8_STRING, and if that fails it tries text/plain;charset=utf-8. It doesn't bother with COMPOUND_TEXT, as I don't think that's common. My feeling is text/plain;charset=utf-8 is becoming more of a standard than UTF8_STRING and that's the fundamental thing at play here. So even if UTF8_STRING being worked out is some kind of bug in my system, I do feel Scintilla should support text/plain;chaset=utf-8.

*1 - This issue was found on Geany, so the patch was built on the Geany source tree which bundles its own copy of Scintilla's source. Hopefully it's not too out of sync with Scintilla main line. This is the downstream bug report https://github.com/geany/geany/issues/2503

*2 - Before the application is closed GTK partly bypasses the X11 clipboard process (it asks X11 where the selection is held then directly requests the contents from that application), bypassing the X protocol. I don't think this has any bearing on the issue [because I know that accessing UTF8_STRING clipboard content via the X protocol does work while the application is open and UTF8_STRING is only lost after it is closed], but may be a further point of confusion for anyone studying this.

[Chris Graham]

Also I think Wayland is using "text/plain;chaset=utf-8", so this patch may make things play nicer with other applications under Wayland.

[Neil Hodgson]

The patch is from a release that is a little old (the atom definitions were changed in [5e6210]) but a bigger problem is that it is based on files with space indentation instead of the original tab indentation. That makes the patch difficult to apply.

Scintilla's clipboard handling was originally written for GTK 1.2 in 1999 when I think there was only asynchronous copy and paste. If it can be rewritten as blocking then that is fine by me. One issue is the weird extra NUL hack to indicate rectangular text as gtk_clipboard_request_text and gtk_clipboard_wait_for_text don't provide sizes.

Its possible that SelectionReceived is for GDK_SELECTION_PRIMARY (look inside selection_data) as ReceivedSelection checks for both GDK_SELECTION_PRIMARY and GDK_SELECTION_CLIPBOARD. However, I don't know of a way to trigger SelectionReceived currently so this may be moot.

Using TRUE as second argument to gdk_atom_intern looks strange when the other calls use FALSE. Its ignored anyway.

[Chris Graham]

Attached patch...

1) Made against latest Scintilla code from Mercurial
2) Follows tabs not spaces (I guess Geany spacified their whole codebase including Scintilla, maybe not the best idea!)
3) Changed gdk_atom_intern TRUE parameter to FALSE. I hadn't given it enough thought. My logic was that if GTK didn't know about this atom already we shouldn't need it, but in such a case I would have had to follow through checking for the none value.

I'm not a developer of anything using the library. I tested this compiles, that's all. But really the code is pretty much identical to what I previously tested on.
I suspect you're right about refactoring. I appreciate what you have done over Scintilla for many many years, but I don't have any spare room in my life to get any deeper into this, so this is as far as I can go. I felt compelled to debug this issue because the Geany folks couldn't reproduce it so I wanted to give something back and not have others possibly worrying they lost code in the clipboard in the future.

[Neil Hodgson]

Committed as [a9f467] but with SelectionReceived and ReceivedSelection changed to use the correct selection so that GDK_SELECTION_PRIMARY should work as well. Unfortunately, the wrong commit message was used for [a9f467] so its a bit confusing.

Also made a change [32db41] to avoid repeating the test for one of the 3 supported string atoms.

[Neil Hodgson]

Committed as [a9f467] but with SelectionReceived and ReceivedSelection changed to use the correct selection so that GDK_SELECTION_PRIMARY should work as well. Unfortunately, the wrong commit message was used for [a9f467] so its a bit confusing.

Also made a change [32db41] to avoid repeating the test for one of the 3 supported string atoms.