1733750 - [Snap] Creating empty directory ~/Downloads/firefox.tmp every time it runs

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Snap, defect)

Description

[doug.hs]

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.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The 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.

Comment 2

[sygczsjy]

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:

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.

Comment 3

[Olivier Tilloy]

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.

Comment 4

[Olivier Tilloy]

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.

Comment 5

[sygczsjy]

"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.

Comment 6

[Olivier Tilloy]

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.

Comment 7

[Alistair Cunningham]

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.

Comment 8

[Olivier Tilloy]

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

Comment 9

[Olivier Tilloy]

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