fix: reverse order of clipboard mime types to work around an apparent Electron bug

[danudey]

Per the discussion in #9532, it seems as though GTK may be treating clipboard mime types as a stack, with the first type created ending up on the bottom and subsequent types ending up above.

In parallel, it seems as though Electron may have a bug where if it encounters an invalid mime type before it encounters one it's willing to accept it will simply fail to paste.

This causes problems when specifying atoms for X11 apps to deal with, e.g. UTF8_STRING, which are not valid mime types. This means that in cases like this:

wl-paste --list-types
text/html
UTF8_STRING
text/plain;charset=utf=8
text/plain

...Electron will reach the invalid mime type UTF8_STRING before reaching the acceptable mime type text/plain and will fail to paste (with no error that I can find).

Reversing the order in which we add these mime types was suggested by @mitchellh, and testing that finds that it does seem to work on my system, but it may be that later versions of GTK change this behavior as a build by @vancluever using GTK 4.18 appeared to be appending types (as would be intuitive) rather than the stack-like behavior I've been seeing.

This will need more testing to ensure that we're not just breaking newer GTK versions instead of older ones.

[mitchellh]

Thanks, it's good to note this does work on your system (and a bit sad!).

Before merging this, I'd love to spelunk a bit deeper into the GTK source or possibly even other protocols like X11/Wayland to understand if this is robust. Is GTK actually doing this on purpose? Is this a side effect of some other system? Can we detect it? etc.

You don't necessarily need to do that, but I want to withhold closing the issue and moving on without some deeper understanding on what's going on here.

[vancluever]

Yeah, I actually think that adding the UTF8_STRING atom might have been unnecessary. Possibly an oversight on my part during testing; I thought that only adding text/plain;charset=utf=8 was insufficient, but it looks like that's fine.

I noticed this because it looks like UTF8_STRING is actually present twice when it's explicitly added.

The following should actually be enough:

const text_provider_atoms = [_][:0]const u8{
    "text/plain",
    "text/plain;charset=utf-8",
};

This is what it looks like in X11 with that:

❯ xclip -o -t TARGETS -selection clipboard
SAVE_TARGETS
TIMESTAMP
TARGETS
text/plain
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/html

At 329aa7d, it looks like:

SAVE_TARGETS
TIMESTAMP
TARGETS
text/plain
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
UTF8_STRING
text/html

So I'm guessing GTK does some stuff, at least on X11, to add all the extra atoms, and the important thing is making sure the explicit UTF-8 MIME specifier (text/plain;charset=utf-8) is supplied as well.

Sorry about this!

I also did do some general diving into the GTK source today and could not really see where the problem might lie. There's code for the orders that preferred (unassumingly while pasting), but it looks like the code for new_union for example has not really changed at all in the last few years, and it seems to do what it says on the tin (setting the providers in the order they're defined).

[vancluever]

Here's my wl-paste with that MIME type list only:

❯ wl-paste -l
text/plain
text/plain;charset=utf-8
text/html

Pasting into Codium also still works.

I think this confirms GTK's handling of things WRT X11 and I'm pretty sure just removing the atom from the list will make it just work, but @danudey you might want to verify too.

[jcollie]

I'm wondering if people are reporting different results based on whether they have a clipboard manager installed or not? The clipboard on Linux is a bit wonky and having a clipboard manager might change the results of any testing.

[vancluever]

No clipboard manager over here, so those results should be just straight from GTK.

For comparison, this is Kitty on X11:

❯ xclip -o -t TARGETS -selection clipboard
TARGETS
MULTIPLE
text/plain
UTF8_STRING

UPDATE funny enough, here's Kitty on Wayland:

❯ wl-paste -l
application/glfw+clipboard-32519
TEXT
STRING
UTF8_STRING
text/plain;charset=utf-8
text/plain

[danudey]

Thanks, it's good to note this does work on your system (and a bit sad!).

Before merging this, I'd love to spelunk a bit deeper into the GTK source or possibly even other protocols like X11/Wayland to understand if this is robust. Is GTK actually doing this on purpose? Is this a side effect of some other system? Can we detect it? etc.

You don't necessarily need to do that, but I want to withhold closing the issue and moving on without some deeper understanding on what's going on here.

I mostly put up this PR (which I forgot to mark as a draft) as a way to get a version of the code that people can test, so I'm happy leaving this open for a bit and/or closing it in favor of a different/better approach.

It might be simpler in the long run to do what Kitty does and detect if we're on Wayland or X11, but there wasn't an obvious way to do that in the current code; Kitty has separate source files for X11- and Wayland-specific functionality which makes context obvious, but Ghostty (thankfully!) relies on the underlying libraries to handle the nits and so doesn't need this difference.

Minorly unrelated to this, I did a quick test with a barebones Electron app and attempted to simply paste text into a <textarea> and it fails there as well. Looks like Electron has had a bunch of wonky clipboard issues for a while, due, it seems, to Chromium changing out some underlying code and Electron having to work around/patch in support/fixes. A refactor of some sort seems to be discussed in electron/rfcs#19, so it seems like it's known that this is kind of a mess and they're working towards a fix. I wasn't able to chase the issue down very far as it goes into Electron's C++ code and then into Chromium's and no thank you sir I don't care about a working clipboard that much.

[danudey]

I'm wondering if people are reporting different results based on whether they have a clipboard manager installed or not? The clipboard on Linux is a bit wonky and having a clipboard manager might change the results of any testing.

So I do have a clipboard manager installed actually and I took a look. When I copy something it has the behavior that I reported, but if I copy that same thing out of the clipboard manager it just shows up as text/plain, so if anything my clipboard manager would probably make things work better and not worse.

[vancluever]

I think the removal of the explicitly-supplied atom should be enough at this point. @danudey if you want to update your side, along with the comments, or I can take this over, up to you. I actually had a PR being prepped when you send this along, hah jinx. 😉.

I can do a bit more plumbing too just to confirm what GTK is doing to massage the MIME types (and possibly even GLFW, I was kind of surprised to see the atoms still present in Kitty).

[danudey]

UPDATE funny enough, here's Kitty on Wayland:

❯ wl-paste -l
application/glfw+clipboard-32519
TEXT
STRING
UTF8_STRING
text/plain;charset=utf-8
text/plain

Here's my Kitty (0.42.2) on Wayland:

wl-paste --list
text/plain
text/plain;charset=utf-8
UTF8_STRING
STRING
TEXT
application/glfw+clipboard-169992

This sure lends credence to the theory that GTK has reversed how it handles the clipboard... except that Kitty doesn't use GTK? So what actual library actually changed? Could this be a change in another library, like libwayland-client? Mine is 1.22.0. Or gtk4-layer-shell? But I'm using -fno-sys=gtk4-layer-shell so I would assume we have the same version. gtk4-layer-shell doesn't work on gnome anyway so it's irrelevant.

[vancluever]

@danudey if you wanted to test this more, I’d definitely try a more cutting-edge version of Ubuntu, and possibly a wlroots-based compositor, in addition to maybe trying it with your clipboard manager off. And yes, Kitty does use GLFW, not GTK, but I’m not too sure how much it plays into their clipboard handling (although the addition of the specific MIME type would indicate there’s at least some interaction there).

Unfortunately I’ll probably be AFK for the rest of the day so I won’t be able to respond, but my Wayland testing was done on niri.

[vancluever]

@danudey any updates on this?

Recapping:

• The UTF8_STRING atom was added erroneously and should be removed. It appears that GTK adds this automatically when running under X11, so we don't need to add it manually.
• We've established that the ordering is not necessarily GTK related, since Kitty's order is being reversed on your machine as well.
• I'm unable to reproduce the ordering issue under niri.

At this point I'm personally skeptical that ordering has anything to do with this. I'd personally be surprised if it did or if any well-behaved application should care about order (they should have their own priority list, like every app that pastes HTML before text (overridden with un-formatted paste, of course).

Again, I'm happy to take this over and see it through, seeing as my commit seemingly caused the regression initially. If you can let me know though that'd be great as I'm eager to at least get the redundant atom removed so that tip is fixed in that regard.

Thanks!

[mitchellh]

Thanks @vancluever for asking, I'm also confused as to what next steps should be. It seems the immediate fix you recommend is only to remove setting UTF8_STRING ourself? And hopefully that resolves the issue?

[vancluever]

@mitchellh yeah, at the very least it should remove the redundant atom as mentioned in #9554 (comment).

I'm getting an Ubuntu 24.04 system set up that I can do some testing on as well WRT Electron, which should hopefully get us some answers on that front.

[vancluever]

PS: Here's some bits from GTK with regards to MIME conversion for X11:

https://gitlab.gnome.org/GNOME/gtk/-/blob/d4d3c60f65ecbf93ac1ec172a50158a6b64f9bcb/gdk/x11/gdkclipboard-x11.c#L170-282

This functionality (gdk_x11_clipboard_formats_to_targets) is eventually rolled into gdk_x11_clipboard_read_async, which should shed some insight how atoms are mapped to MIME types. (https://gitlab.gnome.org/GNOME/gtk/-/blob/3aa9ef7dae736f67d1020cb8de2faf76f264f4ec/gdk/x11/gdkclipboard-x11.c#L796)

Additionally, the docs from gdk_clipboard_read_async:

The clipboard will choose the most suitable mime type from the given list to fulfill the request, preferring the ones listed first.

For Wayland, there's a call directly to gdk_content_formats_match_mime_type (https://gitlab.gnome.org/GNOME/gtk/-/blob/3aa9ef7dae736f67d1020cb8de2faf76f264f4ec/gdk/gdkcontentformats.c#L450-478), referenced in gdk_wayland_clipboard_read_async (https://gitlab.gnome.org/GNOME/gtk/-/blob/3aa9ef7dae736f67d1020cb8de2faf76f264f4ec/gdk/wayland/gdkclipboard-wayland.c#L241), so no special logic for handling of X11 atoms, as one would expect.

Conclusion (sorta)

Notwithstanding read_async not being the primary way clipboard data gets out of a GTK application, I think this pretty much confirms a couple of things:

• Order should not matter, given that reading from the clipboard entails actually requesting types you want,
• GTK does the heavy lifting on X11 for you with atoms, you only need to specify the correct MIME type (explicitly specifying UTF-8 is important here).

One thing that is curious is that Kitty does send along atoms on Wayland as seen (and this does seem to be done explicitly, see x11_window.c and wl_window.c, both in the specfic _glfwPlatformSetClipboard implementations. I kind of wonder if they do this for XWayland? I dunno if I would want to do this 100% unless it was absolutely necessary, especially if GTK isn't doing it for us as it does on X11.

---

PS: One other footnote: it looks like a lot of the clipboard functionality acts similarly for drag/drop (just an aside for possible future work).

[vancluever]

As an addendum, here's some detail in GTK where reading seemed to be an issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/7694

This was fixed recently, which seems suspect, but also the regression referenced in one of the fix commits is recent as well (https://gitlab.gnome.org/GNOME/gtk/-/commit/3f1ec653de766b374e374872bf5d21db8513110d, referenced by https://gitlab.gnome.org/GNOME/gtk/-/commit/bd7ec817c6fa14ee2382602c4aea3e3930b37f75), well after the last Ubuntu LTS release. I'm pretty sure this just has to do with how GTK reads clipboard data, not writes.

[vancluever]

Alright, so results of testing on Ubuntu 24.04:

On main, I was able to confirm that paste does not work in Codium (from the snap store).

wl-paste gives:

$ wl-paste -l
text/html
UTF8_STRING
text/plain;charset=utf-8
text/plain

On my local branch (4f6c5a8), this is corrected: pasting in Codium does work. The order is still reversed.

$ wl-paste -l
text/html
text/plain;charset=utf-8
text/plain

However, using Sway out of apt, the order is fine:

$ wl-paste -l
text/plain
text/plain;charset=utf-8
text/html

So I'm guessing this is a compositor thing - maybe mutter, and other non-wlroots compositors (as niri is also fine).

I'm convinced now that for the time being removing the atom should do the trick. The only thing I can anticipate that may be an issue here after this is XWayland (maybe some old X11 apps that don't look for the MIME type), but I think it might be a good idea to let this cook for a bit (that is, run with a MIME list in Wayland devoid of X11 atoms) before acting on anything else.

I'll throw in my commit for PR so that we can get this merged and resolved for anyone else that might be running into this on tip.