I have an issue with the snap version of firefox 101.0-2:
It keeps changing the actual download directory from /home/username/download to a randomly generated folder in “/run/user/1000/doc/”.
Steps to reproduce the issue:
in firefox settings, set download directory to Downloads folder in home directory and activate “Always ask you where to save files”
download/save first file, this works as it should.
any file download after the first one, firefox will try to save to a folder in /run/user/1000/doc/ and you can see previously downloaded files in that folder too.
in firefox about:config see value of “browser.download.lastDir” has changed to “/run/user/1000/doc/144f6181” with “144f6181” being a random folder
when you delete “browser.download.lastDir” it works once, and after that tries to save to that random folder in /run/user/1000/doc/ again
Things I have tried with no success:
create boolean “browser.download.lastDir.savePerSite” in about:config and set to false
create and set download-directory to “/home/username/snap/downloads” (in the hope that this will be directly accessible for the firefox snap version, thus skipping saving to that /run/user/1000/doc/ folder )
delete places.squite in the firefox profile folder
I’ve recently changed to the snap version of firefox because the newest firefox version wasn’t available through apt anymore.
My system:
Ubuntu Mate Version 20.04.4 LTS (Focal Fossa) 64-bit
Kernel Linux 5.13.0-48-generic x86_64
MATE 1.24.0
I'd appreciate any ideas and solutions for fixing this issue as it is not an option for me to manually set the download path each time I download a file.
I think this is actually not an issue with xdg-document-portal. Firefox is saving the location that the file save dialog returns as the next location to use as a hint when opening a new save dialog. Therefore because the document portal is returning the writable location when the user chooses where to save instead of the location the user chose so that firefox can actually write the file, firefox is not taking into account that it is using the document portal and is blindly saving that portal directory as the assumed target that the user chose.
There’s two issues here, and one of them is potentially severe but I’ve not tested it, but it’s worth looking into.
The first lesser problem is that on Ubutu 20.04 with snaps, the portals are old and don’t check if the snap already has access to the selected file/folder. This means that EVERY file/folder, even those in $HOME will be proxied via /run, even if they don’t need to be.
This is fixed on Ubuntu 21.04+, files will only be mirrored in /run if the snap didn’t originally have access, so this is much less likely to be user visible.
The second issue is that Ubuntu 20.04 portals don’t have support for opening folders at all. It’s opening a file and inferring the folder from the path of the file. Since Firefox has changed it’s behavour recently to automatically download files without asking, this means that Firefox is likely saving directly to the documents store and will experiencing data loss as per Xdg-desktop-portal file loss
I haven’t run this to confirm, but logically I’d suspect that this could quite easily be happening, and should be investigated.
firefox is not taking into account that it is using the document portal and is blindly saving that portal directory as the assumed target that the user chose.
This is correct. Because portals patch the file selection dialogs, there is no way for Firefox to know the real path of a file the user selected. So this is in fact a fundamental design flaw in the way portals work, and there is no way for Firefox to take this into account. It is simply impossible for it to know the information it needs.
This bug also affects opening files and directories from the download manager. If you click “show in folder” or “open file” then the temporary download file/folder will be opened, if it still exists, otherwise nothing happens. If you then subsequently make changes to this file and same them, the changes will appear to have been lost when you subsequently open the file in its true location, and when the temporary directory gets cleaned up, they will truly be permanently lost. So this is a design flaw that causes data loss.
