-
-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xdg-desktop-portal fails when selecting a remote URI from a Flatpak/Snap #820
Comments
A proposed solution was to manually map any remote file to the corresponding Gvfs FUSE mount. This code is available at #814 .With this code, it is possible to save PDF files from Firefox (both in Flatpak and Snap containers) in remote drives, without having to enable VFS in Unfortunately, it's not a very elegant solution. |
By default, xdg-desktop-portal runs with "GIO_USE_VFS=local" to guarantee that it only sends local URIs, but that also means that the user can't access files that are mounted locally using GVfs. This patch filters all the URIs sent and replaces, wherever possible, any remote URI (like sftp://, smb://...) with the corresponding one in the local filesystem created by GVfs. Fix flatpak#213 Fix flatpak#820 Don't use Gvfs Remove the need for Gvfs when accessing files mounted with gvfsd-fuse.
By default, xdg-desktop-portal runs with "GIO_USE_VFS=local" to guarantee that it only sends local URIs, but that also means that the user can't access files that are mounted locally using GVfs. This patch filters all the URIs sent and replaces, wherever possible, any remote URI (like sftp://, smb://...) with the corresponding one in the local filesystem created by GVfs. Fix flatpak#213 Fix flatpak#820 Don't use Gvfs Remove the need for Gvfs when accessing files mounted with gvfsd-fuse.
By default, xdg-desktop-portal runs with "GIO_USE_VFS=local" to guarantee that it only sends local URIs, but that also means that the user can't access files that are mounted locally using GVfs. This patch filters all the URIs sent and replaces, wherever possible, any remote URI (like sftp://, smb://...) with the corresponding one in the local filesystem created by GVfs. Fix flatpak#213 Fix flatpak#820 Don't use Gvfs Remove the need for Gvfs when accessing files mounted with gvfsd-fuse.
By default, xdg-desktop-portal runs with "GIO_USE_VFS=local" to guarantee that it only sends local URIs, but that also means that the user can't access files that are mounted locally using GVfs. This patch filters all the URIs sent and replaces, wherever possible, any remote URI (like sftp://, smb://...) with the corresponding one in the local filesystem created by GVfs. Fix flatpak#213 Fix flatpak#820 Don't use Gvfs Remove the need for Gvfs when accessing files mounted with gvfsd-fuse.
By default, xdg-desktop-portal runs with "GIO_USE_VFS=local" to guarantee that it only sends local URIs, but that also means that the user can't access files that are mounted locally using GVfs. This patch filters all the URIs sent and replaces, wherever possible, any remote URI (like sftp://, smb://...) with the corresponding one in the local filesystem created by GVfs. Fix flatpak#213 Fix flatpak#820 Don't use Gvfs Remove the need for Gvfs when accessing files mounted with gvfsd-fuse.
Proposed patch in xdg-desktop-portal-gnome: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67 |
The work moved to xdg-desktop-portal-gnome so let's track it there |
Several people complain that they can't save files in remote drives (like a SMB mount) from containerized applications (like Firefox). After doing several tests, I found that it worked fine when using xdg-desktop-portal-gtk, but not when using xdg-desktop-portal-gnome. The reason seems to be that xdg-desktop-portal-gtk translates the smb:// URIs (and other remote URIs like sftp://) into locally accessible file:// URIs (thanks to the FUSE backends available with Gvfs), but xdg-desktop-portal-gnome doesn't do that. This patch fixes this by checking each URI obtained from the GtkFileChooser dialog, and if it isn't a "file://" one, it tries to translate it into its FUSE local URI. Also ensure that a trash:/// or a recent:/// URI is transformed into a local one. Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 Fix flatpak/xdg-desktop-portal#213 Fix flatpak/xdg-desktop-portal#820
Several people complain that they can't save files in remote drives (like a SMB mount) from containerized applications (like Firefox). After doing several tests, I found that it worked fine when using xdg-desktop-portal-gtk, but not when using xdg-desktop-portal-gnome. The reason seems to be that xdg-desktop-portal-gtk translates the smb:// URIs (and other remote URIs like sftp://) into locally accessible file:// URIs (thanks to the FUSE backends available with Gvfs), but xdg-desktop-portal-gnome doesn't do that. This patch fixes this by checking each URI obtained from the GtkFileChooser dialog, and if it isn't a "file://" one, it tries to translate it into its FUSE local URI. Also ensure that a trash:/// or a recent:/// URI is transformed into a local one. Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 Fix flatpak/xdg-desktop-portal#213 Fix flatpak/xdg-desktop-portal#820 (cherry picked from commit 8acf01a)
If the user has a remote drive mounted using Gvfs (using SFTP or SMB, for example), and a containerized application calls any of the methods in
org.freedesktop.portal.FileChooser
, the file chooser do show the remote units:If the user chooses a local file, the xdg-desktop-portal works as expected and "tunnels" the file:
But if the user chooses a file in the remote drive, the portal returns no URI:
Also,
xdg-desktop-portal
shows an error in the terminal where it is running (of course, this requires to kill it previously and launch it from a terminal):The test code used (a python program that calls directly to the DBus API) and the JSON file to build a Flatpak is here:
test_portal_python.zip
But it also happens with Firefox in Flatpak: trying to save a page or a PDF in a remote drive mounted using Gvfs fails, and shows the same error in
xdg-desktop-portal
.The text was updated successfully, but these errors were encountered: