Image cut off when pasting into certain applications on Wayland

[j-waters]

Flameshot version
Flameshot v0.10.1 (7199fd3)

Describe the bug

Using Sway version 1.6.1. When I take a screenshot using Flameshot, depending on the size of the screenshot, the image is cut off - and by size, I mean size in mb.

Here's me taking a screenshot of a gradient:

And me taking a screenshot of just a block of red of roughly the same resolution:

As you can see, when I paste the first image into Chrome (or Gimp), it's cut off.

This doesn't happen in every application - I can paste any screenshot into libreoffice just fine, and crucially I can use wl-clipboard to re-copy the image like so:

wl-paste | wl-copy

After I run that, I can past the image into chrome just fine

To Reproduce

Take a screenshot of something complex, then try pasting into Chrome

Expected behavior

For the full image to be pasted

System Information
Arch Linux
Sway version 1.6.1

[j-waters]

If anyone has the same problem as me and wants a temporary solution, I've bound my screenshot key to flameshot gui -r | wl-copy

[mmahmoudian]

@j-waters can you try pasting in github from Firefox and see of the issue persists? We have had some issues with Chrome and I want to make sure that they are not related to this issue you are having.

[j-waters]

Ah it does seem to work in Firefox, that's good to know. It's weird that it also doesn't work in Gimp however

[sethidden]

I can also reproduce this. In the below screenshot I selected the whole j-water's post and pressed CTRL+C. Then I pasted the image from clipboard into GitHub. As you can see, only the first ~25% of the originally selected image is contained in the clipboard

My setup:
Firefox Nightly 98.0a1 (2022-01-18) 64-bit
Flameshot 11.0.0
sway 1.7 (this also happened on 1.6 though)
wlroots 0.15

Relevant parts of my ~/.config/sway/config:

bindsym $mod+Shift+s exec "XDG_CURRENT_DESKTOP=sway flameshot gui"
exec flameshot

j-water's temporary solution with the -r | wl-copy fixes the problem.

[tonyfinn]

Also occuring for me:

Sway 1.7
wlroots 0.15.1
flameshot 11.0.0

Pasting into firefox 99.0 or gimp 2.10.30

Like the above posters, piping into wl-copy is a workaround that worked for me.

[lucidph3nx]

I've been looking for a bug report for this for days and thinking I've gone mad 🤣 here it is, happy now I'm not alone.

Maybe not a flameshot bug, likely something with wlroots but its good to have an issue to follow.

I can confirm the same issue, workaround works but lose a little flexibility that way (cant choose to save to file from there).

Sway 1.7
wlroots 0.15.1-6
Flameshot v12.1.0 (-)
Compiled with Qt 5.15.5

Issue appears while pasting into firefox or electron (21.0.1) apps

I'll add that I've noticed that screenshots that are of a wider aspect ratio seem to be less affected 10-40% blank (black for me) and those of a taller aspect ratio are sometimes as bad as 60% blank. Always at the bottom and in the case of pasting into an electron app (teams-for-linux) it sometimes shows the full screenshot in preview before fully loading to reveal the blank bar. Possible that its some kind of file corruption, I don't know much about this stuff.

[lucidph3nx]

I had another look through the issue list and found this issue that is likely to be related
#3012
I had a go at building #3018 to see if this solved the issue I was having but it seemed to produce a very slow capture window and was just generally buggy, not sure if this is because I built it wrong or what, probably honestly.

I then tested to see if the original bug was still an issue by commenting out the -r | wl-copy workaround and am now able to copy and paste into firefox (107.0.1) and electron apps without the resulting black bar.

I checked my versions and they are identical to my post 2 weeks ago so its unclear what has changed in that time except for the Firefox version. Has anyone else had this miraculously fix itself?

[jack9603301]

@lucidph3nx I think it's weird, but it's not my mistake - even if I use dbus to capture, it still has a very slow selection box speed on my computer. The logic of flameshot screenshot is to first capture the full screen, and then read the picture into it , processed by flameshot, I don't understand why flameshot's processing is so slow (I often have to wait for the selection box to catch up to me)

[alxndr13]

I then tested to see if the original bug was still an issue by commenting out the -r | wl-copy workaround and am now able to copy and paste into firefox (107.0.1) and electron apps without the resulting black bar.

had the same magic effect a few weeks ago, miraculously it did not work anymore after a few days and i was back at the bar issue. Dunno what changed on my system what could have caused it.

[lucidph3nx]

and so, the issue reoccurred today out of the blue and I've gone back to the -r | wl-copy workaround, strange indeed.
sway 1.8 now for a few days, but likely not the cause of the issue.

[mmahmoudian]

@lucidph3nx since we have not released any new version or updated anything recently, this shows that the issue is due to update/change of another software on your computer

[lucidph3nx]

this shows that the issue is due to update/change of another software on your computer

Agreed, With intermittent issues like this, troubleshooting is hard. Its definitely triggered by something else, I said in my first comment that I don't believe this is solely (or even significantly) a flameshot issue, lots of moving parts.

For lack of a better place to discuss, I just thought I would leave as much info as I can for future troubleshooters who may or may not be one of us.

[AkechiShiro]

This issue seems related to #3142

[AkechiShiro]

@lucidph3nx has anyone mentioned this issue upstream to Sway or Wlroots maintainers ?

[lucidph3nx]

@lucidph3nx has anyone mentioned this issue upstream to Sway or Wlroots maintainers ?

I believe there was an issue on the wlroots project at the time, but I struggle to find it now. I honestly gave up on using flameshot, I miss some of its features sometimes (mostly I miss the markup just after taking a screenshot) but 90% of the time, I just want to copy a selection of the screen to clipboard and i get the same effect by using grim+slurp+wl-copy
grim -g "$(slurp)" - | wl-copy

In my now multi-year experience with wayland, I do see software poorly interacting with the clipboard from time to time. Mostly just failing to work, or else being quite laggy. Still, if I had to guess at the cause of this issue, I'd say it was flameshot not interacting with the wayland clipboard correctly.