[Flatpak] [Snap] Do not remember download directory as XDG Document portal directory but user-selected directory
Categories
(Firefox Build System :: Third Party Packaging, defect, P5)
Tracking
(firefox103 affected)
Tracking | Status | |
---|---|---|
firefox103 | --- | affected |
People
(Reporter: gerard-majax, Assigned: gerard-majax)
References
(Blocks 3 open bugs)
Details
(In reply to Alexandre LISSY :gerard-majax from comment #26)
/run/user/<UID>/doc might be expected, but what do you expect <DOCID> to be? It's only valid for one file (the first download), so following downloads will fail.
<DOCID> is something we should not have to care about, it's the xdg ID. I dont know if you can re-use it like you do or if you should go again to your /mnt/itch/Down. It would be useful if you could try several downloads each time manually selecting the correct folder.
It works every time if I manually select the correct folder. That's what I do for every download.
Then mabye the real issue is that we keep in memory the XDG's document path instead of the folder you selected ?
Yes, that seems like the issue to me.
As much as I could understand so far of our interactions there, we delegate handling of the file picker to GTK, and we have no direct notion of the "original good" path that users might expect (e.g, smb://server/share/Path
) and what we get back from the file picker has been processed by the XDG portal and we only get the Portal's Document folder, i.e., /run/user/<UID>/doc/<DOCID>/
. I dont know how much we can fix there.
Assignee | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Thanks! Let me know if you need anymore information.
Comment 2•2 years ago
|
||
This appears to be affecting the firefox snap on Ubuntu 20.04, but not on Ubuntu 22.04 (see https://forum.snapcraft.io/t/firefox-v-101-0-2-download-directory-always-changes-to-run-user-1000-doc/30395). So the version of the document portal plays a role.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
(In reply to Olivier Tilloy from comment #2)
This appears to be affecting the firefox snap on Ubuntu 20.04, but not on Ubuntu 22.04 (see https://forum.snapcraft.io/t/firefox-v-101-0-2-download-directory-always-changes-to-run-user-1000-doc/30395). So the version of the document portal plays a role.
I see this behavior on 22.04.
Comment 5•2 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #0)
As much as I could understand so far of our interactions there, we delegate handling of the file picker to GTK, and we have no direct notion of the "original good" path that users might expect (e.g,
smb://server/share/Path
) and what we get back from the file picker has been processed by the XDG portal and we only get the Portal's Document folder, i.e.,/run/user/<UID>/doc/<DOCID>/
. I dont know how much we can fix there.
FF does know the original good path, because I can enter it manually in about:config. But it doesn't use it for subsequent downloads.
Comment 6•2 years ago
|
||
(In reply to Devin Bayer from comment #5)
FF does know the original good path, because I can enter it manually in about:config. But it doesn't use it for subsequent downloads.
That's not how it works. If I understand the portal's D-Bus docs correctly, what you set in about:config
goes into the portal via the current_folder
argument, then the portal returns a /run/user/<UID>/
path and, because it'd leak information to a potential attacker for a program to be able to recover the un-sandboxed path from the sandboxed one, Firefox has no choice but to assume that you changed the directory from the one it remembers and save the new one.
I can't remember whether a PR has been accepted, but there's been discussion on the xdg-desktop-portal bug tracker around having the file picker do that conversion so apps like Firefox still only see the sandboxed path, but the picker dialogs pretend that only un-sandboxed paths are ever being used, so the user never needs to know that the sandboxed paths exist.
Comment 7•2 years ago
|
||
But if I set the path manually in about:config then the first download works.
Comment 8•2 years ago
|
||
The way FF should do it, is use the configured path for each download. Yes, it gets translated to a new path via the portal - that's fine. But that path will only be valid for a single document.
Comment 9•2 years ago
|
||
Sure. As long as Firefox is configured so that, no matter what you do in the file chooser, it always resets to the about:config
-specified folder the next time, that'd make sense... but then why not just use Flatseal to whitelist that folder so that Firefox sees the un-sandboxed path?
Comment 10•2 years ago
|
||
I do have it whitelisted but that has no effect. The problem is that when I download something, FF uses the download dialog to create a portal doc path which is only valid for that one file. Then it saves that path in browser.download.lastDir
and tries to use it for subsequent downloads. Those downloads silently fail.
Comment 11•2 years ago
|
||
Strange. I only get that behaviour for un-whitelisted paths.
Are you using Snap or Flatpak? Are you using the distro version or a newer version via a PPA? I'm on Kubuntu 20.04, running Flatpak via the PPA referenced via from Flathub's setup instructions and I that updated versions of various components including the backend and GTK frontend for the portal host.
Comment 12•2 years ago
|
||
Ugh. What is my brain doing? "I that" → "I have"
Comment 13•2 years ago
|
||
I am using Flatpak 1.12.7-1 from Ubuntu 22.04, with just distro versions, no PPAs.
Comment 14•2 years ago
|
||
I've got 1.12.7-1flatpak1~20.04
of flatpak
from the PPA, but I'd be more interested in what version of xdg-desktop-portal
you have. The PPA is giving me 1.8.1-1~flatpak1~20.04
.
Comment 15•2 years ago
|
||
ii libportal-gtk3-1:amd64 0.6-2 amd64 Flatpak portal library for GTK 3 GUIs
ii libportal1:amd64 0.6-2 amd64 Flatpak portal library - non-GUI part
ii xdg-desktop-portal 1.14.4-1ubuntu2~22.04.1 amd64 desktop integration portal for Flatpak and Snap
ii xdg-desktop-portal-gtk 1.14.0-1build1 amd64 GTK+/GNOME portal backend for xdg-desktop-portal
ii xdg-desktop-portal-kde 5.24.4-0ubuntu1 amd64 backend implementation for xdg-desktop-portal using Qt
ii xdg-desktop-portal-wlr 0.5.0-3 amd64 xdg-desktop-portal backend for wlroots
Comment 16•2 years ago
|
||
Hmm. Two other questions come to mind, based on my hazy memories of sticking points on my system.
- Can you find the folder in question inside
flatpak run --command=bash org.mozilla.firefox
? Some paths, such as/usr
get overlayed by the Flatpak runtime system and whitelisting them gets ignored. (Something I learned while trying to get integration to work between Flatpak'd Blender and PPA'd MakeHuman. MakeHuman's hot reload protocol assumes that Blender will have the same view of/usr/share/makehuman-community/data
that it does. - Do any of the paths contain symlinks? (I can't remember whether Flatpak had this problem, but Firejail's whitelist directives fail pretty silently if you've done something like symlinking
/srv
to/mnt/Seagate_10TB/srv
or~/.PlayOnLinux
to/mnt/Seagate_10TB/tier3/PlayOnLinux
and didn't remember to whitelist the resolved version too.)
Comment 17•2 years ago
|
||
Yes I do see it, it's outside /usr
and contains no symlinks:
[12:36:39] flatpak run --command=bash org.mozilla.firefox -c 'ls -dl /mnt/itch/Down'
drwx------ 3 dev dev 20 Aug 29 09:52 /mnt/itch/Down
Comment 18•2 years ago
|
||
(In reply to Devin Bayer from comment #17)
Yes I do see it, it's outside
/usr
and contains no symlinks:[12:36:39] flatpak run --command=bash org.mozilla.firefox -c 'ls -dl /mnt/itch/Down' drwx------ 3 dev dev 20 Aug 29 09:52 /mnt/itch/Down
Sorry for going silent for a week.
What does zenity --file-selection --save
output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.
Comment 19•2 years ago
|
||
(In reply to Stephan Sokolow from comment #18)
What does
zenity --file-selection --save
output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.
Sorry. Forgot to clarify. zenity
is available in the runtime the org.mozilla.firefox
Flatpak depends on and uses GtkFileChooserNative
under the hood, so I'm asking what it outputs when you run it inside flatpak run --command=bash org.mozilla.firefox
.
Comment 20•2 years ago
|
||
(In reply to Stephan Sokolow from comment #19)
What does
zenity --file-selection --save
output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.
That gives me a portal path in the firefox flatpak. However in other flatpaks with the same filesystem overrides, even those using the same Freedesktop Platform, it gives me the real path.
I think this isn't the main issue though – I shouldn't have to add my download directory to my filesystem permission override. If I use the file selection box in Preferences to select my download directory, I get a portal path. And that path works for downloads. It's only the 2nd and following download that fail, because FF tries to use the document specific path that it saved in browser.download.lastDir
.
Comment 21•2 years ago
|
||
(In reply to Devin Bayer from comment #20)
I think this isn't the main issue though – I shouldn't have to add my download directory to my filesystem permission override. If I use the file selection box in Preferences to select my download directory, I get a portal path. And that path works for downloads. It's only the 2nd and following download that fail, because FF tries to use the document specific path that it saved in
browser.download.lastDir
.
Ahh. Now I understand. You're describing the open bug, flatpak/xdg-desktop-portal#477: Open file chooser in folder containing specific file.
(Which is a terribly vague-sounding title but is basically requesting that Documents Portal paths be guaranteed to remain unique to a specific permissions grant if you strip off a single path component to get the parent/containing directory, and that the File Chooser portal be guaranteed to reverse the transformation and display the actual un-sandboxed path if given one of them as the starting location.)
Comment 22•2 years ago
|
||
That sounds like it might make it work because I think the issue only occurs when a file selection dialog box is opened. Though that issue has been open for 2 years, it doesn't seem like they consider it the right way to use the API as it currently exists.
Comment 23•2 years ago
|
||
It's a necessary way to support if they want to support the apparent design goal of allowing the backend of things like GtkFileChooserNative and QFileDialog to be transparently swapped out, and I can't think of any simpler way to achieve the desired user experience.
Also, Mikenux (the only person who proposed an alternative approach) isn't part of the development team. He lacks the contributor badge and, from our conversations on flatpak/xdg-desktop-portal#463: Portal to open file and neighbouring files, he's an enthusiastic novice in this space, who leans toward preferring security over convenience to a sometimes impractical degree.
I think it's more like the bugs here that have been open for 12+ years, where they're agreed to be desirable, but no regular has the time to fix them and no volunteer has stepped up to take responsibility for it.
Comment 24•2 years ago
|
||
As an aside, I did figure out why my filesystem permission override wasn't working with FF – the override only worked when set with sudo
and not on the user installation. The flatpak info --show-permissions
output merges them, which is pretty misleading.
I think the best user experience currently achievable is just to always default to the configured download directory and not the last one, at least if it's a portal directory.
Comment 25•2 years ago
|
||
Is there a work around for this please? Whenever I try to download a file now it fails
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 26•2 years ago
|
||
I think the best user experience currently achievable is just to always default to the configured download directory and not the last one, at least if it's a portal directory.
This is not true if, say, the user is saving N images from current web page to directory D. If directory D is not remembered, the user has to navigate to it again for each image.
As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.
Comment 27•2 years ago
|
||
(In reply to Bill Dietrich from comment #26)
As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.
As an alternative voice, please don't break "remember saved-to directory on a per-site basis" for those of us who rely on it and are OK with setting Flatpak manifest permission grants for ths relevant locations to make it work.
This is an XDG File Chooser Portal bug.
(Specifically, the file chooser's get path and set path operations are asymmetric. If the user sets path A and it gets converted to document portal path B on retrieval, then Firefox handing path B back in will not cause the chooser to navigate to path A.)
Comment 28•2 years ago
|
||
OK with setting Flatpak manifest permission grants for the relevant locations to make it work
You may be right, it may be a permissions issue. Saving to local disk seems to remember last-saved, saving to a mounted LUKS volume does not.
Comment 29•2 years ago
|
||
After adding "All System Files" permission to FF in Flatseal, when trying to save to a mounted LUKS volume, the last-saved-to directory apparently is remembered, but actually trying to save a file to it fails silently.
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 30•2 years ago
|
||
(In reply to Stephan Sokolow from comment #27)
(In reply to Bill Dietrich from comment #26)
As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.
As an alternative voice, please don't break "remember saved-to directory on a per-site basis" for those of us who rely on it and are OK with setting Flatpak manifest permission grants for ths relevant locations to make it work.
This is an XDG File Chooser Portal bug.
(Specifically, the file chooser's get path and set path operations are asymmetric. If the user sets path A and it gets converted to document portal path B on retrieval, then Firefox handing path B back in will not cause the chooser to navigate to path A.)
Stephan, do you have an upstream issue to track that? I saw https://github.com/flatpak/xdg-desktop-portal/issues/973 ?
Assignee | ||
Comment 31•1 year ago
|
||
Amin, do you know if we could RESOLVED:FIXED
the present bug in light of https://github.com/flatpak/xdg-desktop-portal/issues/973#issuecomment-1559382416 ?
Assignee | ||
Comment 32•1 year ago
|
||
OK, upstream confirmed this should fix it.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 33•1 year ago
|
||
locally apply https://github.com/flatpak/xdg-desktop-portal/pull/1007 and verify if it fixes as we hope
Assignee | ||
Comment 34•1 year ago
|
||
Locally rebuilding xdg-desktop-portal package on 22.04 and it works.
Assignee | ||
Updated•1 year ago
|
Description
•