This is not a bug in snap. It is a design flaw in xdg-desktop-portal, which Firefox uses to access files outside the container it runs in. This is a flatpak technology which snaps are optionally able to use.

Whenever Firefox wants to access a file outside the container, it shows a file requester where the user can select the file. Gtk and Qt are patched so that whenever a containerized application opens a file requester, they send a DBus request to the desktop portal which makes it show the file requester instead.

The portal then copies the selected file into a directory that Firefox does have access to, and returns the path of that temporary file instead of the one the user selected. This is sent back over DBus to Gtk or Qt, which returns the temporary path from the file requester call.

The intent of this system is to make the portal transparent to applications. But the problem with this is that there is no way for the application or the user to know that an intermediate process has interfered with the selected path.

So there is no way for Firefox to "remember" the directory you selected in the file requester because it never receives it.

The same thing happens when downloading: Firefox is not able to know the location you selected, so clicking on "open file" will open the temporary download location, not the final location. This can lead to data loss if you click "open file" and make changes to the temporary file without realising it is not the copy in the final location, because those temporary files presumably get deleted eventually.