Firefox snap can't open external applications

To reproduce:

  1. Run firefox from snap.
  2. Download a zip file.
  3. In the download popup, click on the file.
  4. In the download popup, click the folder icon.

Result:

Nothing happens.

Expected result:

The zip file should open in archive manager, and the file manager should open on the downloads folder, respectively.

Snap version:

snap 2.51.4
snapd 2.51.4
series 16
ubuntu 20.04
kernel 5.4.0-84-generic

firefox 92.0-3

Additionally, “Save Page As” and “Save Link As” do not work. Again, nothing happens. In fact it seems to be impossible to download any files at all.

you might be missing the right xdg-desktop-portal packages on the host …

Okay I installed it. Now I can download and open files.

They are not saved in the right place though.

Download any file and then open it, or click the directory icon. The opened file is always somewhere like /run/user/1000/doc/6ac0acd0/ and a copy is placed where you asked for it to be saved.

well, this is how portals work. snaps and flatpaks store the files in an area they can write to, the portal hands it to an external app or stores it outside of confinement …

that could probably happen a bit more transparent but i think newer portals than the ones shipped in 20.04 already have improved in that area …

The Firefox flatpak avoids this problem if and only if you save in ~/Downloads. I assume this is because it has write access there, but the snap does not?

the snap does through the home interface … perhaps the default download location should be changed … (though it would have to dynamically adjust itself when the home interface got manually disconnected, i guess that is non-trivial)

Yeah the snap has write access to most of home (confirmed with snap run --shell) however the downloader still insists on using the portal for all downloads, unlike in flatpak where it only uses the portal if it doesn’t have write access to the location you specified.

In all tests I manually selected the location through a file requester, so the default download directory should not be involved.

I’ve also just noticed that it cannot download more than one file at a time.

My mistake. What was actually happening is every time you download or save something, the file requester reverts back to the xdg-portal temporary directory in /run/user, and it refuses to save there, because that’s where the temporary file goes… so it does that every single time you download something, and I forgot to change it. Rather than display an error message, this simply causes the downloads to silently fail.