Firefox 97 on Ubuntu 22.02 saves some temp file in ~/Downloads dir

On Ubuntu 22.04 daily build I started Firefox/snap. I removed this snap and tried Firefox/flapak. But then I decided to move back to Firefox/snap and uninstalled Firefox/flatpak.

Now I notice every time I start Firefox it creates new directory in ~/Downloads/firefox.tmp/ directory. If I delete this directory it is recreated.

In my opinion temp dir does not belong to Download directory.

Does someone else experience this?

A known issue - see Launchpad bug #1958813 and Mozilla bug #1733750

It happens with the Thunderbird snap as well.

1 Like

@PaulW2U, thanks. According to Mozilla report it looks this is not a bug but feature. :slight_smile:

This temp files/folder is according to report to enable other snaps to have access to Firefox/snap downloads.

I may be old “fashioned”, but I somehow expect to get the same result regardless of the type of package management the program is installed by.

I know snaps are containerized, but it should be some other way to enabled this, specially when Firefox/snap in Ubuntu 22.04 becomes default way of being distributed. Am I too harsh?

an alternative to using the current dir would simply be to have an auto-connected personal-files interface allowing access ~/.firefox.tmp (note the dot, so it will be hidden) for temporarily downloaded files, not sure if this has been discussed … @oSoMoN would know though …

Is the “proper” solution here to not set the writable flag to true in the XDGp OpenFile call?

While it wouldn’t work on the current 20.04 release because of an old package of the portals, on newer releases, setting that flag to true will determine whether to use the document portal to ensure the recieving application has access to it. In the context of older distributions with older packages, the Firefox solution makes sense, but in an ideal world where everything is modern, I was under the impression this is already solved.

(And if you’re a Flatpak, the flag already works even on 20.04).

I’m unsure exactly how Firefox is triggering the DBus call, but I’ve commented in the past that I think writable=true should be the default for e.g the xdg-open implementation in the Core snaps, because IMO this makes sense the vast majority of the time vs the current default.

It seems Mozilla is working on a new feature that will, indirectly, address this issue - see here.

Not sure how this new “Download panel improvement” would deal with the problem, but this is Mozilla response, apparently.