| Summary: | For Flatpak apps, clipboard does not paste images if backed by a file the app doesn't have access to it only wants a file path | ||
|---|---|---|---|
| Product: | [Plasma] xdg-desktop-portal-kde | Reporter: | Wyatt Childers <kdebugs.81do7> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aleixpol, caucusgrating600, kde, nate, sitter |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Wyatt Childers
2025-06-19 09:25:48 UTC
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. |