[snap] I have on clean install some weird folder /home/user/Downloads/firefox.tmp/

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

Steps to reproduce:

1. Install Ubuntu 21.10 (impish). It ships with Firefox installed as a Snap that is maintained by Mozilla.
2. Check the ~/Downloads directory, it should be empty
3. Run Firefox.
4. Check the ~/Downloads directory, it should now have an empty directory named "firefox.tmp".

Actual results:

An empty directory is being created at ~/Downloads and I believe this is not the intended behavior. The directory never goes away, it just stays there. If you delete it, it will be recreated when you run Firefox again.

Expected results:

It shouldn't create temporary files in my Downloads directory.

The [Bugbug](https://github.com/mozilla/bugbug/) bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0

I have observed the same problem. Ubuntu 21.10, default installed Firefox, Snap version 93.0 according to About Firefox.

If the user deletes the directory ~/Downloads/firefox.tmp/ while Firefox is running, Firefox may recreate it at a later point. In some cases the directory is empty. In other cases, it contains temporary files.

My best guess is that it has to do with a change noted in [this thread](https://forum.snapcraft.io/t/xdg-open-not-working-on-firefox/17670/14):

> There’s no `mimeapps.list` file any more, and the `snapcraft.yaml` now sets `GTK_USE_PORTAL=1` in the environment. This causes the GLib APIs to ask `xdg-desktop-portal` to open any files it can’t otherwise find a handler for.
>
> The other change in tip is to set `$TMPDIR` to somewhere other than `/tmp` (specifically, it sets it to `~/Downloads/firefox.tmp`). When Firefox tries to open a file of a type it doesn’t understand, it downloads and saves a copy of it to the temp files directory, and then tries to open that file with its associated handler. This is a problem for snaps, since `/tmp` inside the sandbox is different to `/tmp` outside of the sandbox. Using a different location allows the file to be passed to the helper outside the sandbox.

This is actually intended: it was added in https://hg.mozilla.org/mozilla-central/rev/015f42782c5e, to ensure that other snaps can open files downloaded by firefox. See https://forum.snapcraft.io/t/sharing-files-via-tmp/1613 for details.

And with https://git.launchpad.net/~mozilla-snaps/+git/firefox-snap/commit/?id=f7022494b8d02835617be47226cd55d455ee84fd I moved the workaround and added a comment to make the intent clearer.

"Downloads" seems like an inelegant place for the firefox tmp dir. Downloads is normally the directory for files the user downloads, whereas software usually stores its temporary files in a hidden directory like `.cache` or `.local/share/`. The effect is that the user's Downloads directory is intruded upon by the seemingly random files like a `mesa_shader_cache` directory. Perhaps the firefox temporary directory could be placed in a less obtrusive location.

Of interest, is bug 1710926 : if I set `browser.download.improvements_to_download_panel` to `true`, then files are downloaded to the default Downloads directory, instead of a temporary directory, and the downloads panel is shown, instead of a dialog to ask the user what to do with the file.

Once that setting becomes true by default, we can simply remove the `TMPDIR` hack.

Am suffering from a similar problem, which is that Firefox 99.0.1 running on Ubuntu 22.04 creates $HOME/firefox.tmp and $HOME/snap directories without being asked every time it starts.

The `TMPDIR` workaround has been removed with https://github.com/canonical/firefox-snap/commit/250d24a72953fd797a10ec2fe338fcd0fe2491ff in the beta branch.

And the change has now been propagated to the stable branch, and released with 101.0.