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.

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

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.