xdg-desktop-portal
xdg-desktop-portal copied to clipboard
flatpak
Firefox and Thunderbird do not correctly remember a previous file operation's target directory and then saving a file doesn't work
The following weird behaviour happens both in Firefox and Thunderbird and was reported to Mozilla at bugzilla 1785158 and also mentioned here.
This happens on Ubuntu 22.04 with default flatpak installed, using 1.14.0-2flatpak1~22.04.1 from the ppa.
Step 1
This is working as expected.
- try to save a file such as
16586934064490.jpgfrom Thunderbird or Firefox - the file chooser appears
- I can choose a target location directory such as
/tmp - I can change the target filename if desired
- in the end, the file is stored at the chosen target location as expected.
Step 2
This is a bug.
- right after successfully saving a file in step 1
- try to save a different file with the same file type, such as
IMG_6521.jpg - the file chooser appears
- but the file chooser now doesn't show me the
/tmpdirectory with all of its files as the target directory for the second file, but instead shows me a virtual/run/user/1000/doc/<hex_id_number>directory that only contains one file, the file16586934064490.jpgthat was stored in step 1 - as a naive user I'm assuming that the second file would now be stored into the same directory from step 1
- I can select this target location in the file chooser
- neither TB nor FF complain or show an error message about it
- the second file is never stored anywhere and just silently dropped
Based on @j-wiedemann's comment in https://github.com/flathub/org.mozilla.Thunderbird/issues/266, here's another odditiy:
If I use ~/Downloads as the target folder instead of /tmp, the two steps described above work as expected. In Step 2, the correct directory is shown to me and the second file is stored there as expected.
This is expected as thunderbird flatpak has direct access to ~/Downloads thus it bypass portal for this path.
Do you mean it happens only for /tmp and not for any other path?
In general portals translate host paths to container paths and the latter are in /run/user/1000/doc/<hex_id_number> and this is what apps see.
The problem here is that Firefox and Thunderbolt are trying to point the filechooser folder to a path that they don't necessarily have access to. Funnily enough, this behavior would have been automagically added on GNOME if these apps didn't try and do it. KDE and others can easily implement the same behavior on their portal backends too. I've shared this comment on Firefox bugzilla.
I'll close this issue because it's not something that can be fixed in xdg-desktop-portal.
I don't know about Thunderbird, but Firefox has a "Remember last path on a per domain basis" feature and I consider that valuable enough that I'll be customizing manifest permissions to keep it working for the domains I visit frequently until I no longer need to.
Or, alternatively, because so many applications do things in that vein via the directory argument to QFileDialog's constructor (or QFileDialog::setDirectory and QFileDialog::setDirectoryUrl) and things like the set_current_folder* family of GtkFileChooserNative functions with the broken link to "why you shouldn't use this" documentation (probably as a result of a simple port from GtkFileChooser), #477 should be resolved by having it so that, when an application asks to pre-open to the parent of a document portal path, the chooser opens to the folder that path is a mapping from.
(Especially considering that, if that "why you shouldn't use this" behind the broken link is what I think it is, then it's going to be a hard sell when Windows needs you to manually remember last used paths in cross-platform applications and it has a much larger market share and people don't like having to be responsible for maintaining and testing multiple code paths.)
...is it ever useful for a portal-opened file chooser to display the /run/user/.../doc/... path? Is it ever not surprising and confusing for users?
...is it ever useful for a portal-opened file chooser to display the /run/user/.../doc/... path? Is it ever not surprising and confusing for users?
Please refrain from adding these snarky, loaded questions. They do nothing but devoid the very few people working on these things of motivation.
It isn't intended to be snarky, so I apologize for not anticipating that interpretation and altering my phrasing to rule it out.
It's intended as an honest question. Was that an intentional decision which serves a purpose that's not obvious to me, or merely a default "lack of code to do otherwise" behaviour?
To the best of my knowledge, that's the mapped path that Firefox receives from the document portal. It then tries to restore that path, and succeeds, but that's really not what it should have restored. The file mapping is important for sandboxed applications since that's how external files find their way into the sandbox. From inside the sandbox, apps cannot predict nor hint the filesystem layout like Firefox tries to do. We would need to extend the filechooser portal API to accommodate for some sort of "restore path token" which then portal backends could use to match both app id, and token. Firefox would send as a restore path token, the domain of the website, and with that it can replicate the current behavior.
That's my understanding of it too, but, as someone who knows nothing about how it's implemented, it seems obvious that:
- A solution to ensuring that users never see a document portal path in the privileged file choosers (i.e. that "last used" document portal paths either get mapped to their non-portal-path destinations if they exist or get treated the same as nonexistent non-portal paths if their destinations can't be resolved to an existing path) is orthogonal to anything concerning how those paths get chosen as what the dialog should be pre-opened to.
- The file chooser is privileged code running outside the sandbox, which still requires the user to click OK before the application sees anything, so I don't see how it's dangerous to resolve document portal paths to keep users from seeing what should be mere implementation details.
- Unless there's some need to significantly rearchitect something designed without sufficient prescience that I'm unaware of (are the document portal paths not globally unique?), it would make sense that the chooser, being privileged code, should be able to use the document portal path as the "restore path token" and make "set pre-opened directory" operations symmetrical with "return selected path" and restore the location state that the dialog was in when the user originally clicked OK when requesting to create that document portal path.
- I don't know how Firefox does it, but its "remember a different 'last used' path for each domain" feature successfully manages to provide a "please pre-open to here" path to the portal-provided KDE dialogs when manifest permissions take the document portal paths out of the equation so it can see the actual filesystem paths.
Given that it's the same KDE dialogs with or without the manifest permissions (As evidenced by KDE's "Only show when using this application" option for Places sidebar entries saying the application is "xdg-desktop-portal-kde" and Firefox not having Chrome's kdialog-based fallback for invoking KDE dialogs) and Firefox successfully enacting different "last used" paths for different domains when using manifest permissions, the only issue appears to be that "Please open the dialog already navigated to this path" is not symmetrical with how the path returned by the previous use of the dialog was produced. (A conclusion supported by how I've never observed one domain's manifest permission "last used" path getting disrupted by another domain's document portal "last used" path.)
I agree, the mapped path should be the "restore path token" implicitly. That behavior is most likely desired should be the default without any changes to existing applications.
If there actually is a use case for exposing the user to the mapped path in the file chooser, then this should be handled via a special flag or something, because this would be much more rare.
the mapped path should be the "restore path token" implicitly
This looks like the proper solution that I wasn't able to phrase this cleanly when writing the issue report. Indeed, that would lead to the application behaviour I had expected.
I'd like to remind folks that in step 2, the user not only gets to see the portal path (which is undesired behaviour), but also the user's save action of a second file into that portal path location results in the second file being silently discarded with no error feedback to the user (even more undesired).
I still have the issue and yes I just discovered that if I discard a file in the run/user location it disapears from my normal folder !! I actually discovered it because I tried cutting and pasting a file from that run/user location into the desired folder. It disapeared from both.
Why was this issue closed ? This behavior is a MAJOR pain in Firefox when saving images from a web page, for example. The user has to do lots of extra clicks to navigate to the same destination directory for each image.
...or grant --filesystem for the directories in question, which is what I do to work around this, a reduction in security, and the exact opposite of their stated goals.
Yes.. I actually lost many files two weeks ago because I reformated a partition... A partition which was NOT where I had saved them. But it's where firefox somewhow decides they were "really" stored. So now I use other ways to download the important things... Send them to myself through email etc.
Still thinking that this is buggy behaviour and made issue #973 to suggest a possible fix that would nudge application developers to fix this on their side of the code.