Bug 867073

Okay, this sounds reasonable.

This fix/feature will be part of next security update which should be available around November 20.

The fix is bad, IMO.

Why is a user-defined $TMPDIR ignored?
Why does the /usr/bin/firefox script override it with a hardcoded /var/tmp?

This has broken Claws Mail, which tries to prevent multiple instances from being started: bug 956390 - When started via Firefox mailto handling, Claws Mail ends up with a different temp dir compared with when started within GNOME Shell (or the user's session).

> Source21:       firefox.sh.in

What is the current upstream status with regard to that file? I have downloaded upstream's firefox-21.0.tar.bz2 archive, and it does not include a script that overrides TMPDIR. run-mozilla.sh doesn't mess with TMPDIR.

correct Claws Mail ticket: bug 956380

Fedora decided to use tmpfs for /tmp (tmp in memory). When opening big files this could lead to filling all available space in /tmp easily (and also occupy half of system memory). We've decided to use /var/tmp which is by default on root partition. The TMPDIR was hardcoded in /usr/bin/firefox script, then MOZ_TMPDIR has been introduced to override it. 

I agree that overriding user defined TMPDIR isn't correct. I'll fix that by avoiding to set TMPDIR to /var/tmp when it was already defined as environment variable. You will have to set TMPDIR variable before you run Claws anyway.

About firefox.sh - this file is not from upstream, because upstream does not cover distribution specific issues.

The solution I'd favour is to have /usr/bin/firefox evaluate TMPDIR and use it for setting a private MOZ_TMPDIR used within Firefox. If TMPDIR and perhaps TMP and TEMP (in that order) are not set, have MOZ_TMPDIR default to /var/tmp, but not override the empty TMPDIR in the env of launched programs. That way, launched programs can keep their own defaults, e.g. glib2 defaults to /tmp if no env var is set.


> You will have to set TMPDIR variable before you run Claws anyway.

Only since the firefox script has introduced a hardcoded /var/tmp, which isn't in sync with the default path of other temp dir methods.

Quoting from bug 956380 comment 5:
|
| Claws Mail on the other hand relies on g_get_tmp_dir(),
| which reads the env vars TMPDIR, TMP, TEMP (in that order),
| and if none is defined, defaults to /tmp.

(In reply to Michael Schwendt from comment #7)
> The solution I'd favour is to have /usr/bin/firefox evaluate TMPDIR and use
> it for setting a private MOZ_TMPDIR used within Firefox. If TMPDIR and
> perhaps TMP and TEMP (in that order) are not set, have MOZ_TMPDIR default to
> /var/tmp, but not override the empty TMPDIR in the env of launched programs.
> That way, launched programs can keep their own defaults, e.g. glib2 defaults
> to /tmp if no env var is set.

I'm afraid that's not possible. A MOZ_TMPDIR was introduced to allow override TEMPDIR to content MOZ_TMPDIR content. Firefox binary doesn't read MOZ_TMPDIR variable, it reads TMPDIR as any other application.

> 
> 
> > You will have to set TMPDIR variable before you run Claws anyway.
> 
> Only since the firefox script has introduced a hardcoded /var/tmp, which
> isn't in sync with the default path of other temp dir methods.
Do you explicitly set TMPDIR variable on your system? If so with next update the Firefox will honour this preference, but if TMPDIR isn't defined we'll set default tmp dir to /var/tmp.

> Quoting from bug 956380 comment 5:
> |
> | Claws Mail on the other hand relies on g_get_tmp_dir(),
> | which reads the env vars TMPDIR, TMP, TEMP (in that order),
> | and if none is defined, defaults to /tmp.

> Do you explicitly set TMPDIR variable on your system?

Occasionally. That means, for some accounts. It isn't required by Claws Mail, however. It will be required when some parts of Fedora default to /tmp and others default to /var/tmp.

> If so with next update the Firefox will honour this preference,
> but if TMPDIR isn't defined we'll set default tmp dir to /var/tmp.

Better than nothing. Thanks!

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.