Allow to override TMPDIR

[rpellerin]

Why does TMPDIR have to be in ~/Downloads? It does not make sense to have temporary files in the user's Downloads folder.

Could we please have a chance to override export TMPDIR=$(xdg-user-dir DOWNLOAD)/thunderbird.tmp? Or we can have this temporary folder automatically removed after Thunderbird is closed?
Thank you.

[MarkyMarkDE]

same we have for firefox (~/Downloads/firefox.tmp) and additional thunderbird or firefox one or both writes a mesa_shader_cache folder in ~/.cache but this folders we have in our profile folders and these will be also filled!
Why we get trash on many places?
Please solve this unlogical stuff so soon as possible.

[gpelz-graph-it]

Using Thunderbird with user dirs on the network having no option to change the tmp-dir is a problem.
Before I symlinked ~/.cache to a local folder, so the cache-/tmp-dirs were not in the network, but locally. Now they are on the network which delays handling attachments&co noticeable. Having no option/way to change the location of the temp directory really is a problem.

[PimpOfSune]

Using Thunderbird with user dirs on the network having no option to change the tmp-dir is a problem.

Lack of easily accessible official non-snapd package is a problem. As per https://bugzilla.mozilla.org/show_bug.cgi?id=1925353 , junk in user's folders is a consequence of bad preferred packaging choice.

I as "just a user" am under impression that I can't install non-snapd version of Thunderbird anymore as "just a user".
So I'll probably have to migrate to a different solution.

[gpelz-graph-it]

Any update regarding an option to overwrite the location?

[nteodosio]

The fix is now merged.

[nteodosio]

Hey, just a heads-up, this caused a regression and has therefore been reverted, as the bug trumps the inconvenience described by this issue.

It turns out that TMPDIR will then be /tmp (surprise! :p), which is private to the snap, so handlers will look into /tmp/attachment will find nothing.

The inconvenience remains acknowledged but I won't be able to look into it in the near future. I think maybe a easy stop-gap would be to move it to $SNAP_COMMON/ so that it doesn't clutter the more relevant downloads folder. If you have a patch with that or one that doesn't cause the unintended side-effect, I'll gladly have a look.

[qflen]

Came back to this after some time @nteodosio

[Hativ]

When will this make it into the release?

About Thunderbird says:

153.0 (64-bit)
Mozilla Thunderbird Snap for Ubuntu
ubuntu-snap-build - 1.0

But thunderbird.tmp is still being created in ~/Downloads.

[nteodosio]

It was again reverted because of #67.

I submitted to beta an attempt to defer to user's choice but that fails and always take the else branch:

# Set TMPDIR to be under the user's default Downloads dir
if [ -z "$TMPDIR" ]; then
    TMPDIR=$(xdg-user-dir DOWNLOAD)/thunderbird.tmp
else
    >&2 echo "The environment variable TMPDIR was set by the user. " \
             "He thereat acknowledges the risk of hitting $bugs."
fi

Given the linked bug we will definitely not change the default behavior so it must be improved.

Any suggestions? One could of course honour some other variable name (e.g. CUSTOM_TMPDIR) but it would be even more undiscoverable. Another possibility is to change the check to [ "$TMPDIR" = /tmp ] (as it is what snapd sets it to), but the problem is that surely some users would try to set exactly to that value, so from the scripts' perspective it is unable to tell whether it comes from the user or from Snapd and therefore if it should override it or not.

[PimpOfSune]

Any suggestions?

Well, non-snapd non-flatpack Thunderbird packages were reintroduced sometime ago, no?
Which is good! I have no intent nor desire to jump through all those hoops because people in a year 2026 still can't learn to not run binaries attached to mails sent from unknown people.

Route A: an issue to snapd / canonical / whatever requesting to reduce excessive security nobody asked for and hope for best in few more years. Given that even Steam is still having hiccups due to all those apparmor shenanigans... and it's been for two years currently.
Route B: resort to non-snapds non-flatpaks if you don't need extra layers of security.
Route C: run whole Mozilla's joint insecurely in secure virtual machine, if you insist on security.
And that's it.

Running applications,
which are supposed to interact with each other,
in high-security per-application sandboxes,
with multiple layers of security checkup on each app-to-app communication attempts,
simply couldn't be a good idea in the first place.