SUMMARY Pasting an image to a flatpak fails if the image is copied by (seemingly) reference to the file path (and the flatpak doesn't have access to said file path). STEPS TO REPRODUCE 1. Install the Signal flatpak 2. Open an image in $HOME/Pictures in Gwenview and "Copy" it 3. "Paste" the image in Signal OBSERVED RESULT Signal is unable to access the file (by virtue of the flatpak sandbox) EXPECTED RESULT Signal's access to the file is allowed SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 64 GiB of RAM (61.9 GiB usable) Graphics Processor 1: AMD Radeon RX 7900 XTX Graphics Processor 2: AMD Radeon Graphics Manufacturer: ASUS ADDITIONAL INFORMATION This is not an issue for images coming from e.g., Spectal or GIMP's copy button. There seems to be a problematic secondary clipboard "copy" functionality (that's presumably a path reference rather than the image contents themselves?). I was hoping this would be resolved with the clipboard portal (https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/2de83ee0e0349cac3447ff3be1e05e53cf9e6246). However, it does not appear that was the case. Drag-and-drop from Spectal, Gwenview, or Dolphin is similarly busted though that's likely a separate issue.
When I copy an image in gwenview raw image data is also advertised in addition to the file path. I guess signal prefers loading the image itself via the path? Maybe apps on the host side also need to pass it through the exportUrlsToPortal https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kurlmimedata.h#L69
I am not sure it makes sense to track this here, it needs fixing in the source host apps like drag and drop did. FWIW the clipboard portal is something for remote desktop.
(In reply to David Redondo from comment #2) > I am not sure it makes sense to track this here, it needs fixing in the > source host apps like drag and drop did. > > FWIW the clipboard portal is something for remote desktop. It seems like there should be a way for the clipboard to work in a flatpak if it works on the host without changes to the apps themselves... Maybe that's not possible. I did not know what exactly the clipboard portal was, so that's good to know.
The problem is that an app on the host side says that a file at /some/path/file is in the clipboard there's no guarantee that an app in the sandbox can actually see the file. So there's work needed to talk about files inside/outside the sandbox
(In reply to David Redondo from comment #4) > The problem is that an app on the host side says that a file at > /some/path/file is in the clipboard there's no guarantee that an app in the > sandbox can actually see the file. > > So there's work needed to talk about files inside/outside the sandbox Is that work that needs to happen with flatpak/bubblewrap itself perhaps? I could envision "clipboard file access" being a permission where the flatpak would expose a file path on the clipboard upon a "paste from the clipboard." Similar to how browsers disable their popup-blocking rules to allow popup windows "on click" so that common user usage patterns continue to work.
We could maybe do something like this for clipboard with Klipper.
We've had a bit of a chat and we think we have a solution that can work some references: paste receiver https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/plugins/platforms/wayland/qwaylanddataoffer.cpp?ref_type=heads#L151 paste sender https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/plugins/platforms/wayland/qwaylanddatasource.cpp?ref_type=heads On the sender side we'd offer an application/vnd.portal.filetransfer whenever a uri is present. On the receiver side we'd always prefer the application/vnd.portal.filetransfer when inside a sandbox. And request data for it. On the sender we receive the data request and run portalization logic for the uri, then give the transferid as reply to the data request. On the receiver side we do the portal-transfer dance to get access to the uri inside the portal. Caveat is that this only considers wayland native for now. We'll have to see what we do with x11. May well be that this also opens an avenue for Qt native drag and drop support.