Core dump running cb with image copied from firefox in the clipboard

[prurigro]

Describe the bug + To Reproduce

After copying an image to the clipboard from firefox, running cb prints the following:

/usr/include/c++/14.2.1/span:286: constexpr std::span<_Type, _Extent>::element_type& std::span<_Type, _Extent>::operator[](size_type) const [with _Type = unsigned char; long unsigned int _Extent = 18446744073709551615; reference = unsigned char&; size_type = long unsigned int]: Assertion '__idx < size()' failed.
Aborted (core dumped)

This happens both if I compile it myself, as well as when I use the pre-compiled binary on the releases page.

Copying something else to the clipboard fixes the issue. I'm also able to run cb copy file.jpg as well as copy the same image in chromium and run cb without issue, so it's specifically when copying an image from firefox.

Version

Version 0.9.0 on ArchLinux using clipboard-linux-amd64.zip from the releases page.

Additional context

I'm not sure if it helps, but I'm running wayland.

[Slackadays]

Ok, sorry for the wait! This has happened a couple times to me before. The problem has been certain kinds of accesses to arrays somewhere, but they're hard to diagnose because it generally only happens on the very latest compiler versions. If you install CB using something like Flatpak, does that work instead?

[Slackadays]

Unable to reproduce so this looks like a "too new" compiler problem, closing if no response soon

[prurigro]

Sorry about not responding earlier, I missed your reply 3 weeks ago.

So I tested with the flatpak version, and while the core didn't dump like the prebuilt version from github did, the behaviour isn't exactly as expected either. What happens is it says "There is currently nothing in the clipboard", and then instead of closing, I get a cb process running in the background that steals focus for a fraction of a second every second or so before returning it. If I run it again I get a second cb process running in the background doing the same, and they only seem to go away when I manually kill them (though I didn't wait an excessively long amount of time).

Similar to the prebuilt github version, the flatpak works correctly with images copied from the gimp or chromium.

[Slackadays]

Then this is a dupe of #171, the fix is for someone, anyone, to write the C++ code to interface with the special wlroots clipboard protocol

[prurigro]

Is that the same issue as being unable to see the contents of the clipboard when an image has been copied via Firefox? (It sounds like I just happened to run into #171 at the same time, and assumed it was a related bug because they occurred together)

[Slackadays]

Not the same, but it still is close-worthy because I've seen this multiple times and the root cause turns out to be that the compiler is too new, leading to subtle bugs like this one that aren't actionable because they depend on the compiler.

[prurigro]

I'm not hitting the crash on the flatpak version though, it just doesn't see the contents of the clipboard there. I'm not sure if the issue is related to the fact that the github version was crashing, but if I understand you correctly, the flatpak version shouldn't be observing the compiler issues? If this is the case I wouldn't mind switching to that, but it still can't interact with images from firefox.

[Slackadays]

All Flatpaks use a compiler version that tends to lag behind the latest and greatest, so that's why you don't see the crash there. However, I can't reproduce the Firefox issue, so I'm not sure what to do there.

[prurigro]

So you're right clicking and selecting Copy image in firefox, then running flatpak run app.getclipboard.Clipboard and it lists the contents correctly? Is it possible that this is a difference between the wayland and x11 clipboards on that note? I just realized that chromium is running under xwayland while firefox is running natively.

EDIT: Confirmed- running chromium with --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto makes it so copied images don't appear in clipboard.

[Slackadays]

Then I think I might know the problem: if it gets something, anything, from X11 first, it doesn't check Wayland. There might be some kind of content coming from the X11 side first and that prevents CB from getting anything from Wayland, or in your case, Firefox.

[prurigro]

It is able to get text from firefox and chromium on wayland. Maybe images are handled differently though?

[Slackadays]

I'm not sure, but since I almost never use Wayland, I'll need to check that out.

[prurigro]

Let me know if there's any testing I could do that would be helpful, and thanks for looking into this :)

[prurigro]

So I played around a bit, and it seems like when you cat an image into wl-copy then run wl-paste, it outputs the raw image. When you copy an image from firefox however, wl-paste doesn't output anything. Here's the interesting part though, if you then run wl-paste > out.jpg, you get the image saved in jpg format, but if you run wl-paste > out.png, you get the image in png format... They even have different file sizes!

I'm not sure what the source format looks like, or how it knows to convert to the destination format, but I suspect this is what's tripping cb up. It also means that I can't directly pipe the paste buffer into cb using the script method.