Open Bug 1785158 Opened 2 years ago Updated 8 months ago

flatpak Firefox does not remember its last used directory storage location in "Save" file dialog

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 106
defect

Tracking

()

UNCONFIRMED

People

(Reporter: hanno.zulla, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

I'm currently making my local collection of user manuals for the devices I own, thus I am downloading various PDF files to a local directory structure on my NAS.

Using flatpak Firefox on Ubuntu 22.04, I search for user manuals, find them on the manufacturer's website, click on the user manual PDF file.

The user manual PDF file will be displayed in Firefox's internal PDF viewer. There, I click "Save Document".

Things work as expected on the first PDf file - I can choose the desired target directory and safe the file there.

On any subsequent PDF file, the desktop environment's File Dialog (Ubuntu 22.04 Gnome in my case) will not show me the same directory location I used before.

Instead, the File Dialog will show me a virtual "/run/user/1000/doc/<hex_id_number>" folder that only contains the file I stored previously, even if there are more files than the previous file in the target directory.

Firefox will not complain when I try to save the new file to that virtual folder which contains the old file, but the file is not saved. Apparently, the new file is silently discarded.

To actually store the new file, I have to choose the target directory again. Then things work as expected.

Actual results:

  • Open a first document (or image file) in a tab

  • Click "Save" to have it copied to your local filesystem

  • Using the file dialog, choose a target directory e.g. "/tmp/" and save the 1st file there

  • Open a second document

  • Once again, click "Save" for the 2nd document

  • Look at the folder path shown in the file dialog

  • In my case, it's not "/tmp/", but a virtual "/run/user/1000/doc/<hex_id_number>" folder

  • The virtual folder only contains the 1st file I previously stored, even though "/tmp/" contains several other files

  • If I do nothing and just confirm the file dialog's default choice, Firefox will close the file dialog, as if everything worked as expected. Instead, the second file isn't stored anywhere.

  • Click "Save" for the 2nd document, again

  • Now choose "/tmp/" again as the target directory in the file dialog

  • The file dialog will show the files in "/tmp/", including the 1st file

  • Saving will actually save the 2nd file to "/tmp/"

Expected results:

  • For the 2nd file, the file dialog should return the user to the last used target directory. On the 2nd click to the "Save" menu item, I had expected to see the "/tmp/" directory where I stored the previous, 1st file.

  • There should be an error message if the user wrongly tries to write to the virtual "/run/user/1000/doc/<hex_id_number>", files should not be silently discarded.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Version: Firefox 103 → Firefox 106

Firefox should not have to try and manually set the file chooser dialog path. Implementations of the filechooser portal can implement remembering the last path that a sandboxed application used - in fact, the GNOME portal implementation already supports that, see https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/55

Still an issue as of version 108.0.1

Still an issue in version 109 after a fresh install of ubuntu

Blocks: flatpak
Priority: -- → P3

This is still an issue in version 114.

This seems to be an upstream xdg-desktop-portal issue. PR #1007 https://github.com/flatpak/xdg-desktop-portal/pull/1007, which is merged, should fix this issue.

Please check the xdg-desktop-portal version. In xdg-desktop-portal 1.18.0 and later this problem should be fixed.

Flags: needinfo?(hanno.zulla)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(hanno.zulla) → needinfo?(stransky)

I'm on Ubuntu 22.04, which does not provide xdg-desktop-portal 1.18.0.

To test it, I installed version 1.18.0 packages from the latest Ubuntu release plus all other packages it required to be updated.

xdg-desktop-portal_1.18.0-1ubuntu1_amd64.deb
libc6_2.38-1ubuntu6_amd64.deb
libc-bin_2.38-1ubuntu6_amd64.deb
libfuse3-3_3.14.0-4_amd64.deb
locales_2.38-1ubuntu6_all.deb

After doing that, flatpak applications cannot open or save any files to the filesystem.

No idea if 1.18.0 solves the initial bug report. But this much I can say, a partial upgrade to that version broke my system.

Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.