Fix copy failure on GNOME via GUI by no7076 · Pull Request #4363 · flameshot-org/flameshot

no7076 · 2025-11-04T11:25:23Z

My suspicion is that GNOME and specifically Mutter requires specific trusted context for the QtClipboard (from 'kf.guiaddons: Could not init WaylandClipboard, falling back to QtClipboard.') clipboard operation. This means that a visible window must provide the clipboard data. Since the daemon has no visible window, this is a workaround that makes the 'flameshot gui' window handle the copying with a slight delay using QTimer to ensure that GNOME has requested the clipboard data and saved it.

This seems like a better solution to #4355 as no helper windows are needed, since we already have the 'flameshot gui' window and can use it. I've limited it to GNOME only as I cannot easily test in other environments.

Fixes #4116, #4298

My suspicion is that GNOME and specifically Mutter requires specific trusted context for the QtClipboard (from 'kf.guiaddons: Could not init WaylandClipboard, falling back to QtClipboard.') clipboard operation. This means that a visible window must provide the clipboard data. Since the daemon has no visible window, this is a workaround that makes the 'flameshot gui' window handle the copying with a slight delay using QTimer to ensure that GNOME has requested the clipboard data and saved it. This seems like a better solution flameshot-org#4355 as no helper windows are needed, since we already have the 'flameshot gui' window and can use it. I've limited it to GNOME only as I cannot easily test in other environments. Fixes flameshot-org#4116, flameshot-org#4298

WizardlyBump17 · 2025-11-08T03:13:02Z

I can confirm this fixes it on Ubuntu 25.04 with Wayland

EDIT: weirdly when trying to take a screenshot from the keyboard it just sends an error notification. I am going to investigate that tomorrow

WizardlyBump17 · 2025-11-08T19:05:08Z

I can confirm this fixes it on Ubuntu 25.04 with Wayland

EDIT: weirdly when trying to take a screenshot from the keyboard it just sends an error notification. I am going to investigate that tomorrow

Well, that is interesting. If I set the command to be bash -c "flameshot gui" it works fine. If I create a file with flameshot gui as its content and make it executable, it also works fine, but setting the command to be just flameshot gui doesnt...

B4T3S · 2025-11-08T19:08:20Z

I can confirm this fixes it on Ubuntu 25.04 with Wayland
EDIT: weirdly when trying to take a screenshot from the keyboard it just sends an error notification. I am going to investigate that tomorrow

Well, that is interesting. If I set the command to be bash -c "flameshot gui" it works fine. If I create a file with flameshot gui as its content and make it executable, it also works fine, but setting the command to be just flameshot gui doesnt...

I don't think this is a new issue though. I had to use the bash -c workaround a while ago when I first started using flameshot

mmahmoudian · 2025-11-09T07:37:42Z

Thanks for the PR. This looks like a much cleaner approach. I wonder if 150 nanoseconds in QTimer is arbitrary, based on trial and error, or it has some connections with mutter's interal logic?

All3xJ · 2025-11-09T18:47:33Z

I tried to compile and install it, but clipboard copy still does not work. I have Fedora 42

no7076 · 2025-11-09T20:17:58Z

Thanks for the PR. This looks like a much cleaner approach. I wonder if 150 nanoseconds in QTimer is arbitrary, based on trial and error, or it has some connections with mutter's interal logic?

It is arbitrary. Unfortunately I couldn't find a more precise method for this, so I just arrived at this 150ms delay. I'd be happy if someone comes with something more deterministic, maybe I can look into it further too in the following days.

I tried to compile and install it, but clipboard copy still does not work. I have Fedora 42

I just tested this on a freshly installed Fedora 42 Workstation and clipboard copy worked as expected after the patch. Could you confirm you've fully rebuilt after applying the patch, and also ensure that you're using the newly-built binary?

borgmanJeremy · 2025-11-11T01:37:50Z

Thanks for this, it at least can put us on the right track. I'm a bit hesitant to merge it since its a somewhat arbitrary delay.

Is there a reason the full screen capture widget cannot act as the visible window before its closed? For example have the clipboard data saved while the UI is fullscreen, before its closed?

Do you have any references from Gnome that explains this behavior we could link to to keep track of it?

no7076 · 2025-11-17T18:04:18Z

Thanks @borgmanJeremy for the feedback, I took another shot at this.

The arbitrary 150ms delay is now gone. The GUI capture widget now provides the clipboard data directly and stays alive only until the compositor actually requests it. For this deterministic behavior, I introduced a small helper class, ClipboardWatcherMimeData, which inherits from QMimeData. This subclass overrides retrieveData() so we get a callback the moment Mutter pulls the image bytes. When that method is invoked, we immediately signal the capture widget to close itself. The 500ms timer that’s still in the code is only a safety net so we don’t hang forever if GNOME never pulls the data; under normal conditions this shouldn't fire.

Is there a reason the full screen capture widget cannot act as the visible window before its closed? For example have the clipboard data saved while the UI is fullscreen, before its closed?

That’s exactly what happens now: the capture window itself calls QClipboard::setMimeData() while it’s still the focused, visible client, then hides and only exits once GNOME has read the data. The dbus+daemon path is now never used for copying on GNOME.

Do you have any references from Gnome that explains this behavior we could link to to keep track of it?

The behaviour comes from Mutter’s Wayland clipboard implementation: src/wayland/meta-wayland-data-device.c, the key method is meta_wayland_data_device_set_selection(), which checks (I think here) whether the requesting client is currently the focused one; if not, the selection request is rejected or the source is cancelled. This is why the copy fails on GNOME when Flameshot's GUI window closes before calling setMimeData().

Once GNOME has accepted the selection, its clipboard manager copies the data into its own buffer so it can keep serving it after the original client goes away. That logic is defined in src/core/meta-clipboard-manager.c, primarily in owner_changed_cb(). The compositor iterates over the offered MIME types, chooses one (image/png in our case), and requests the data via meta_selection_transfer_async(). If the original owner disappears, the manager takes over the clipboard using its cached data.

Just a heads up that I’m by no means deeply familiar with Mutter. But with the current patch the copy succeeds on GNOME 48.

borgmanJeremy

Thanks! This approach makes much more sense to me in the long run. I want to test on gnome before merging but can do that in the next couple of days. Thanks again.

borgmanJeremy · 2025-11-18T01:41:13Z

+
+    // Safety net: force close after 500ms if compositor never fetches
+    QTimer::singleShot(500, keepAlive, [keepAlive]() {
+        if (keepAlive)


Can you add a warning to the log if this happens? If we get bug reports of the clipboard not working it would be good to know if it was due to this timeout.

simonhammes · 2025-11-18T08:41:47Z

Thanks @borgmanJeremy for the feedback, I took another shot at this.

Just to give an additional data point: I tested your changes on Fedora 43 (gnome-shell 49.1, mutter 49.1.1) and copying to the clipboard worked flawlessly 🎉

borgmanJeremy · 2025-11-25T00:59:26Z

Sorry about the clang-format, I'm ready to merge this once thats resolved (assuming the rest of the CI passes).

no7076 · 2025-11-25T05:21:48Z

Of course, applied clang-format, hopefully it is good now.

pmorch · 2026-01-06T01:26:55Z

This works on NixOS 25.11 under Gnome with Wayland too, where the stock v13.3.0 was broken. Here is the nix overlay file I used to build it: flameshot-on-gnome-wayland.nix

(I had to rename it to a .txt file for github to allow me to upload it, but it should end in .nix)

B4T3S · 2026-01-06T06:28:41Z

Does anyone know when we can expect a new release? I would love to have this fix available without building from source, but I couldn't find anything regarding a release schedule ^^

mmahmoudian · 2026-01-06T18:43:26Z

@B4T3S no stable release is planned yet. There are few Wayland issues that we are trying to fix before a release. Stay tuned, and until then , building from source is super easy and straightforward:

https://flameshot.org/docs/installation/source-code/

B4T3S · 2026-01-07T06:26:48Z

@B4T3S no stable release is planned yet. There are few Wayland issues that we are trying to fix before a release. Stay tuned, and until then , building from source is super easy and straightforward:

https://flameshot.org/docs/installation/source-code/

Alright! Thanks for the reply ^^

Just would've been nice to be able to rely on my package manager to update for me, instead of having to check in every now and then to see when the new release is out and I can switch back

mkomko · 2026-01-07T07:14:48Z

Just would've been nice to be able to rely on my package manager to update for me, instead of having to check in every now and then to see when the new release is out and I can switch back

Haha, same for me 😉

brianjmurrell · 2026-02-05T13:54:46Z

This is a serious enough bug that it deserves a bug-fix release at least.

@B4T3S no stable release is planned yet. There are few Wayland issues that we are trying to fix before a release.

Can we not let the perfect be the enemy of the good? New releases don't need to wait for everything known to be fixed. You will never do a new release if you follow that philosophy. New releases should be made any time there is any bugfix available, IMO.

Anyone wanting a new package on Fedora could go vote on the Fedora Bugzilla issue I just opened to have this patch landed to their package while we wait here for a new release. While you wait for that, I have rebuilt the current Fedora flameshot with this patch included in my copr repo for Fedora 42, 43 and rawhide.

* Fix copy failure on GNOME My suspicion is that GNOME and specifically Mutter requires specific trusted context for the QtClipboard (from 'kf.guiaddons: Could not init WaylandClipboard, falling back to QtClipboard.') clipboard operation. This means that a visible window must provide the clipboard data. Since the daemon has no visible window, this is a workaround that makes the 'flameshot gui' window handle the copying with a slight delay using QTimer to ensure that GNOME has requested the clipboard data and saved it. This seems like a better solution flameshot-org#4355 as no helper windows are needed, since we already have the 'flameshot gui' window and can use it. I've limited it to GNOME only as I cannot easily test in other environments. Fixes flameshot-org#4116, flameshot-org#4298 * Keep capture window alive until GNOME fetches clipboard data * Move the GNOME clipboard workaround in screenshotsaver.cpp * Log GNOME clipboard timeout and restore success notification * Apply linter fixes

Upstream release candidate (tag v14.0.rc1, internal FLAMESHOT_VERSION 14.0.0). Follow Fedora pre-release convention: Version: 14.0~rc1 with %autorelease -p, yielding Release 0.1.fc44. - Drop 0001-fix-copy-failures.patch; flameshot-org/flameshot#4363 is merged into v14.0.rc1. - Bump bundled Qt-Color-Widgets to 5d52e907e5 (tracks upstream FetchContent pin; library version still 2.2.0, Provides unchanged). - Pass -DDISABLE_UPDATE_CHECKER:BOOL=ON (new upstream option; Fedora disables auto-update checks per packaging guidelines). - Introduce %global src_tag so Source0 can reference the literal GitHub tag "v14.0.rc1" while %{version} uses the Fedora ~rc1 form. - %autosetup -n %{name}-%{src_tag}, matching the tarball top dir. Verified via fedpkg --release f44 mockbuild --enable-network; all four RPMs build cleanly, %check (appstream + desktop-file-validate) passes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

no7076 mentioned this pull request Nov 4, 2025

Fix copy failure on GNOME #4355

Closed

verils mentioned this pull request Nov 11, 2025

Fedora 43 (Gnome 49) : app doesnt start #4368

Closed

no7076 added 2 commits November 17, 2025 17:27

Keep capture window alive until GNOME fetches clipboard data

1bd4ba4

Move the GNOME clipboard workaround in screenshotsaver.cpp

632b7a1

borgmanJeremy reviewed Nov 18, 2025

View reviewed changes

borgmanJeremy mentioned this pull request Nov 18, 2025

fix: copy selection to clipboard #4332

Closed

Log GNOME clipboard timeout and restore success notification

142c009

Apply linter fixes

4ce8ea5

borgmanJeremy merged commit 535032b into flameshot-org:master Nov 28, 2025
24 of 26 checks passed

mmahmoudian mentioned this pull request Nov 28, 2025

Screenshot copying to clipboard doesn't work #4298

Open

yajo mentioned this pull request Dec 9, 2025

Flameshot clipboard doesn't work in sway. NixOS/nixpkgs#181759

Open

beexon mentioned this pull request Dec 30, 2025

Wayland: --clipboard reports success but clipboard is empty (Fedora 43, GNOME 49, Qt 6.10) #4460

Closed

Conversation

no7076 commented Nov 4, 2025

Uh oh!

WizardlyBump17 commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WizardlyBump17 commented Nov 8, 2025

Uh oh!

B4T3S commented Nov 8, 2025

Uh oh!

mmahmoudian commented Nov 9, 2025

Uh oh!

All3xJ commented Nov 9, 2025

Uh oh!

no7076 commented Nov 9, 2025

Uh oh!

borgmanJeremy commented Nov 11, 2025

Uh oh!

no7076 commented Nov 17, 2025

Uh oh!

borgmanJeremy left a comment

Choose a reason for hiding this comment

Uh oh!

borgmanJeremy Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

no7076 Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

simonhammes commented Nov 18, 2025

Uh oh!

borgmanJeremy commented Nov 25, 2025

Uh oh!

no7076 commented Nov 25, 2025

Uh oh!

Uh oh!

pmorch commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

B4T3S commented Jan 6, 2026

Uh oh!

mmahmoudian commented Jan 6, 2026

Uh oh!

B4T3S commented Jan 7, 2026

Uh oh!

mkomko commented Jan 7, 2026

Uh oh!

brianjmurrell commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

WizardlyBump17 commented Nov 8, 2025 •

edited

Loading

pmorch commented Jan 6, 2026 •

edited

Loading

brianjmurrell commented Feb 5, 2026 •

edited

Loading