311292 - Can't specify download location of temp files on Mac

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Nori Heikkinen]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

If I have the action associated with the filetype PDF set to "open," when I
click on a link to any PDF, Firefox will save the file to my desktop, and then
open the file with my specified app.  When I quit, this file is still there, and
still cluttering up my desktop.

There appears to be no place for a user to specify his/her preference of a
temporary files directory.  While I realize the Desktop is the default Mac
temp-files directory, the location to which Firefox downloads temporary files
should be user-specifiable.

Cursory googling suggests setting the download location in Safari to your
preferred temp folder; this does not work.

Reproducible: Always

Steps to Reproduce:
1. Under Prefs -> Downloads, set the action associated with PDF to "open"
2. Click on any PDF link
3. Quit out of the app that opens to view the file
4. View your desktop -- voilà, a file you don't want there.

Actual Results:  
A file was downloaded to the desktop.  For every summary click on the same PDF
link, another copy is downloaded to the desktop.

Expected Results:  
It should have downloaded the file to a temp-files directory of my specification.

Comment 1

[Hiro]

dup bug191385 ?
If it is so, WONTFIX .

Comment 2

[Nori Heikkinen]

Sorry, I forgot to address that I'd already looked at bug 191385, and decided
that this wasn't a duplicate bug -- that one asks for the *expected* behavior to
download to /tmp, and it was concluded on that thread that this should not be
what Firefox does by default; I'm asking that there be a *preference* for
setting where the $TMPDIR is.  I maintain that it's distinct from this earlier
bug due to the nature of the request. 

Comment 3

[Mark Mentovai]

If Firefox won't save files to be opened in external applications to the
appropriate spot in /tmp (that was bug 191385), it should at least save to the
"save all files" folder from the preferences, if set.  If "ask me" is set
instead, then I've got no problem using ~/Desktop for files passed to externals.

Comment 4

[Nori Heikkinen]

It doesn't.  Try setting your "save all files" pref to ~/Documents, then click
on a PDF link.  Same behavior -- it still downloads to the ~/Desktop.

Comment 5

[Uri Bernstein]

seems like a dup of bug 263830 and/or bug 278647, both unconfirmed. See also bug
201291.

Comment 6

[Mark Mentovai]

http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1515

We're using the download directory as configured in the system, ~/Desktop by
default.  I'm able to work around this by resetting the download folder in
Safari.  Camino is affected but works around by using Internet Config to reset
kICDownloadFolder in its Downloads pref pane.

The code reference above is the only significant place that
NS_<MAC|OSX>_DEFAULT_DOWNLOAD_DIR is used.

Comment 7

[Mark Mentovai]

Attachment: Save files for launch in the download folder, if any, else the desktop

This actually does affect Camino, albeit in a much more subtle way.

The patch is sort of unclean in that the "save all downloads to" behavior is
controlled by the embedder, not uriloader/exthandler.  Launching temps, which
is the problem here, is controlled exclusively in exthandler.  Short of adding
an interface to pull this information out of the embedder, exthandler needs to
peek into preferences that it doesn't own in order to solve this problem.  I
don't like the idea of adding an interface because embedders don't generally
care about temp files like this, and in a sense, it's none of their business. 
Except on the Mac, that is.

I might be inclined to minus the patch myself just on that principle.  I guess
it's not the end of the world, though.	These aren't the first prefs in the
browser.download branch that exthandler is looking at, and always falling back
to the desktop is no worse than the existing behavior.

Camino/Seamonkey and Toolkit (Firefox and the rest of the menagerie) use
slightly different prefs to determine the save-as location, and this patch
interprets both styles.

P.S. Josh, I whacked some more XP_MAC for ya.

Comment 8

[Asaf Romano (gone)]

Comment on attachment 198949 [details] [diff] [review]
Save files for launch in the download folder, if any, else the desktop

The depedency on the toolkit/xpfe implementations isn't a plan. Minusing, as it
seems we already come up with a better approach.

Comment 9

[Mark Mentovai]

Mano's right.  Also, the original proposed patch breaks Camino, which uses the
system's download directory for everything.  We'll solve this with a new pref
that embedders can write (and should write on the Mac) and that exthandler
respects; the fallback on the Mac will be the desktop.

Comment 10

[Mark Mentovai]

Attachment: Introducing a pref for this purpose

This introduces browser.helperApps.launchTempDir and
browser.helperApps.useLaunchTempDir.  If useLaunchTempDir is true,
launchTempDir is the directory that will hold files for launch.  The pref is
false by default.  On the Mac, these prefs shadow Firefox' download folder
prefs.	On other platforms, they're left alone.  I've also included the
necessary changes to the Safari profile migrator to import the proper behavior.


Camino will need to be modified accordingly.

Comment 11

[Mark Mentovai]

Attachment: The right file

Comment 12

[Asaf Romano (gone)]

Comment on attachment 199123 [details] [diff] [review]
The right file

Index: mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp
===================================================================

+  nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
+
+  PRBool useLaunchTempDir = PR_FALSE;
+
+  if (prefs)

This isn't correct XPCOM usage. Use the two-argument form of
do_GetService instead.

+  if (!NS_SUCCEEDED(rv))

if (NS_FAILED(rv)) instead?


Index: mozilla/browser/components/preferences/downloads.xul
===================================================================
+      <preference id="browser.helperApps.useLaunchTempDir"
+		   name="browser.helperApps.useLaunchTempDir"
+		   type="bool"/>
+      <preference id="browser.helperApps.launchTempDir"
+		   name="browser.helperApps.launchTempDir"
+		   type="file"/>
Index: mozilla/browser/components/preferences/downloads.js
===================================================================
+#ifdef XP_MACOSX
+      // On the Mac, the directory used to hold files for launch follows the
+      // downloads directory.
+      var launchTempDirPref =
document.getElementById("browser.helperApps.launchTempDir");
+      var useLaunchTempDirPref =
document.getElementById("browser.helperApps.useLaunchTempDir");
+      launchTempDirPref.value = file;
+      useLaunchTempDirPref.value = 1;
+#endif

The <preference> binding is a bit expensive. As those has no UI, use the
preferences ifaces directly instead.

Also, if launchTempDir is already set and useLaunchTempDir is off, we shouldn't
turn it on.

Index: mozilla/browser/components/migration/src/nsSafariProfileMigrator.cpp
===================================================================
   aBranch->SetIntPref("browser.download.folderList", equals ? 0 : 2);
   aBranch->SetComplexValue("browser.download.defaultFolder",
			    NS_GET_IID(nsILocalFile), downloadFolder);
+  aBranch->SetComplexValue("browser.helperApps.launchTempDir",
+			    NS_GET_IID(nsILocalFile), downloadFolder);
+  aBranch->SetBoolPref("browser.helperApps.useLaunchTempDir", PR_TRUE);


Add a comment on what behavior we're importing here.

mail/ needs parallel changes.

Comment 13

[Mark Mentovai]

Oops, I wanted to do this for fox2 but forgot.

Comment 14

[Mark Mentovai]

I'll do this for fox2 if it gets blocking, otherwise, it'll sit longer.

Summary: right now, when the action for a download is set to open in an application, the temp file is saved in Safari's download folder.  From the user's perspective, it seems pretty strange to use another app's pref for one sort of download when the Firefox prefs have a provision for a download folder that isn't influenced by settings in other apps.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

We definitely want to stop littering the desktop, but I'm not sure why we wouldn't observe *our* default download location instead of Safari's. What's the rationale there, Mark?

Comment 16

[Mark Mentovai]

Beltzner and I were talking about this after clearing up the confusion.

We do want to stick temp files passed to external handler apps in the downloads directory set in the Firefox prefs, if such a setting exists and is valid.  If the user has selected "always ask me where to save," we need to do something smart with the file.  It's probably easiest to just stick the file on the desktop in that case.

It would also be nice for the temp file location to be independently adjustable (via a hidden pref) so that Mac users who want temp files to go somewhere like /tmp can do that.  That's the standard behavior on other platforms, but not on the Mac.  Bug 345397 will make it easy to set such a pref on the Mac.

Comment 17

[Mike Connor [:mconnor]]

Not going to block on this at this point, but would take a safe patch.

Comment 18

[Ray Kiddy]

Are these all dupes of each other? Or perhaps related to another meta-bug?


Bug 263830 – "Open With" download option uses System 'Downloads' folder as temporary directory (edit)
Bug 311292 – Can't specify download location of temp files on Mac (edit)
Bug 360790 – [Mac] Have some default choices for helper apps in the download manager (edit)

Comment 24

[Robin]

I was wondering if there was any progress on this issue.

It seems more important than ever now, as since Safari 3.0.4 there is no longer any way to change the download directory Firefox is using for 'Open With' files.
At the moment the situation is somewhat bizarre, in that what is a temporary
directory on other platforms, is hardcoded (and impossible to change) to the
users desktop on the Mac, which many people find annoying.

I don't mean to go on, but from the discussions I think a lot of people don't
realise what a pain this is. My workflow of gathering references and reading
pdfs online is now completely changed, as I have to decide immediately whether
to keep or delete a viewed file, or else the desktop quickly becomes
unmanageable with cryptically named files. (A lot of online journals give files
with numerical names etc.)

Could we please have a configurable directory for the 'Open With' files, or at least use the specified Download directory instead of the users desktop.

Comment 25

[Oakwine]

(In reply to comment #24)
> Could we please have a configurable directory for the 'Open With' files, or at
> least use the specified Download directory instead of the users desktop.

Note that Leopard (10.5) now creates a ~/Downloads directory.  Firefox should find that directory as well.

Comment 26

[Robin]

(In reply to comment #25)
> Note that Leopard (10.5) now creates a ~/Downloads directory.  Firefox should
> find that directory as well.

As far as I know, ~/Downloads is a regular directory, just with a fancy icon. It is possible to change other apps (eg Safari) to save there, or to other directories. Other than it being a sensible default for the "Save As" directory I don't think it's that relevant to the problem here. (I'm not sure what you mean by Firefox should "find it as well").

I'm keen to keep things as simple and clearly stated as possible, since I believe there is then more chance they will get some attention.

At the moment, the normal downloads setting for saved files works fine, and can be set to ~/Downloads if the user likes (this is also a sensible default value).

At the moment, the directory used to save files when "Open With" is selected is hardcoded to the users desktop, and there is no way, in Firefox, or elsewhere within the OS, to change this setting. There should be a new configuration option to allow the user to set this directory as they choose.

Comment 27

[Robin]

It would be great if the target milestone could be moved to a release that hasn't already happened.

Comment 28

[Robin]

I found a workaround, but it's fairly complicated.
http://forums.mozillazine.org/viewtopic.php?p=3220730#3220730
The preference firefox uses is stored in ~/Library/Preferences/com.apple.internetconfig.plist as the DownloadFolder preference. By opening this in a plist editor it is possible to identify the bytes representing this key in the file, and change it manually with a hex editor, replacing 't' with an 'f' in several places, which results in it using ~/Deskfop instead of ~/Desktop.

However I don't think is a viable worksaround for most users, and believe the target milestone should still be changed.

Comment 29

[Jonathan Payne]

It's great the version 3, beta 4 browser is faster, fewer memory leaks, etc., but isn't it a little strange that such basic functionality is beyond the capabilities of these obviously great developers? Is the code too complex or is this bug not important enough? Not being able to specific a download folder for months and months and months seems very strange to me.

Right up there with not being able to press the Back button and ending up scrolled to the same position in the document as before, although this gem is even more basic to browsing the web.

This post probably violates etiquette but it needs to be said some place.

Comment 30

[Jonathan Payne]

OK - I have figured out how to solve this problem for OS X Leopard. What I have learned is this file:

     ~/Library/Preferences/com.apple.internetconfig.plist

indeed does whole the "system-wide preference" for the download folder. But what I read elsewhere on the web is, When you change the value in Safari, it no longer updates that preference in the above file.

So what I did was delete the 'DownloadFolder' property within the 'ic-added' dictionary from that file, and now Firefox is happily using the directory that is specified in firefox's preferences. (Save the original file if you're worried about it.)

But now I've noticed that I cannot change it in Firefox and have it change. It's just using my ~/Downloads folder now, and nothing I do, including changing Safari's preference and changing my Firefox preference, will make it go into any other folder.

Comment 35

[Rahul Abrol]

to be clear, NS_OS_TEMP_DIR is in the Users directory, ~/Library/Caches/TemporaryItems (not /tmp) and it's only deleted on computer restart (not application restart), so the reasoning for distinguishing OSX in bug 191385 no longer seems to apply.

is the conditional comp. in http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1169 and #2181 still necessary?  removing it would be a temporary fix until this bug gets resolved.

Comment 36

[Per Olofsson]

The workaround in comment #30 worked for me. Temporary files now end up in the ~/Downloads folder, which isn't perfect, but much better than ~/Desktop. Together with browser.helperApps.deleteTempFileOnExit set to true, things are almost sane again.

The easiest way to delete the DownloadFolder key is probably to use Property List Editor, but not everyone has the devtools installed, so here's a command that you can paste into the terminal (on 10.5, earlier osx releases don't have PlistBuddy in a friendly location):

/usr/libexec/PlistBuddy -c "Delete :Version\ 2.5.4:ic-added:DownloadFolder" ~/Library/Preferences/com.apple.internetconfig.plist

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The best work around for now will be the Multi-Safari option. Just download an older version of Safari and make the changes there. The download is available here: http://michelf.com/projects/multi-safari/

Mark, do you plan to update your patch or aren't you interested anymore in?

Comment 39

[Till Korten]

To my opinion, the problem why this bug has not been fixed for three years (!!!) is probably due to the fact, that many mac users are inexperienced in filing bugs or even searching bugzilla. Therefore this bug does not get many votes. However the many duplicates of this bug show that there definitely is a need for a fix.

Also, there has been some confusion, that this might be a feature specific to the needs of mac users. However, since even Apple changed this behavior in Safari, and does not use the system default download folder in any of its applications any more (or support the changing of this setting), I think it is safe to assume that this is really a bug and not a feature!

Please, everyone who reads this bug and has the same problem, take the time to vote for this bug! Maybe, if it accumulated enough votes, we can attract the attention of the responsible developer.

Comment 40

[Tyler B]

Ahh I wish there was a way I could vote for this bug 100x.  If Mark has given this up, is there a way to indicate that the bug is unassigned?

Comment 41

[Ray Kiddy]

(In reply to comment #36)

> 
> The easiest way to delete the DownloadFolder key is probably to use Property
> List Editor, but not everyone has the devtools installed, so here's a command
> that you can paste into the terminal (on 10.5, earlier osx releases don't have
> PlistBuddy in a friendly location):
> 
> /usr/libexec/PlistBuddy -c "Delete :Version\ 2.5.4:ic-added:DownloadFolder"
> ~/Library/Preferences/com.apple.internetconfig.plist

I have a Tiger system (10.4.11) and I do not have PlistBuddy. FYI, one can use the defaults command to edit an arbitrary plist file. See 'man defaults' for details. I suspect that this command is more commonly available.

Comment 42

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #41)
> I have a Tiger system (10.4.11) and I do not have PlistBuddy. FYI, one can use
> the defaults command to edit an arbitrary plist file. See 'man defaults' for
> details. I suspect that this command is more commonly available.

This way didn't work for me. I wasn't even able to read this property. See my comment 37 for the easiest solution. I did this some hours ago on my system and no all temporary files are stored under ~/Library/Caches/TemporaryItems.

Comment 43

[Per Olofsson]

(In reply to comment #41)
> > /usr/libexec/PlistBuddy -c "Delete :Version\ 2.5.4:ic-added:DownloadFolder"
> > ~/Library/Preferences/com.apple.internetconfig.plist
> 
> I have a Tiger system (10.4.11) and I do not have PlistBuddy.

Chances are that you do, but it's not in a consistent location. Try find /Library/Receipts -name PlistBuddy

> FYI, one can use
> the defaults command to edit an arbitrary plist file. See 'man defaults' for
> details. I suspect that this command is more commonly available.

Unfortunately the defaults command doesn't handle nested key/value pairs.

However, with PlistBuddy, Property List Editor, and Multi-Safari there should be a workaround for everyone.

Comment 44

[Shawn Wilsher :sdwilsh]

Mark, are you working on this anymore?

Comment 45

[Rubén Marrero]

This bug really need to get looked at, as there are even more side effects of not being able to control *where* do the temp files get written to.

I have a MacBook Pro (intel, late 2006) that got it's video card hosed. I backed up my user account to an external HFS disk and used an older Mac Mini (PPC, late 2004) to keep working by creating a new in-between acct. Both machines use Tiger w/ latest updates.

My original MBP user account $HOME was /Users/ruben
My new in-between account $HOME is /Volumes/LaCie/Backups/ruben

Firefox 3 works great until I click on anything that would trigger a download. It fails there with the following message:

"No se pudo guardar /Users/ruben/Desktop/vn4_5BjQ.dmg.part porque usted no puede modificar el contenido de esa carpeta."

that's Spanish for "Can't save /Users/ruben/Desktop/vn4_5BjQ.dmg.part because you can't modify the content of that folder."

FF3 hard-coded somewhere it's download location at my prior $HOME. I've grepped both ~/Library/Mozilla and ~/Library/Application Preferences and found nothing. Nothing shows on about:config either.

So, summing it all up:

  * opening any URL that would trigger a download. FAILS verbosely as I've described before
  * right-click on an image, choose "Save this image as.". OK USING the UI "donwload location" preferences correctly.
  * right click on a link, choose "Save this link as.." FAILS silently

Hope it helps. switching to Safari in the meantime :-(

Comment 46

[Shawn Wilsher :sdwilsh]

Folks, please stop commenting that this bug also impacts you.  This is what votes are for.

Comment 47

[Rubén Marrero]

K, voted :-)

but still methinks that adding yet another user case for the bug would help.

Comment 50

[Alex Monras]

I have already voted for this. I think the developers, in their ivory tower, have lots of reasons to put their temporal files in the desktop but that does not mean that the average joe has them too.
As for myself, the only reason I didn't switch to safari is the Zotero extension.

Please, hear our call

Comment 51

[Till Korten]

since Mark Mentovai's last comment (#16) was  more than two years (!) ago and he did not answer a mail that I wrote him two months ago, I think it is safe to assume, that Mark does not continue to work on it. So Please reassign it to someone else (or unassign it until somebody else takes charge).

This bug has increased in severity recently, since from safari version 3 you cannot use the setting in safari as a workaround. This is also evident from the many recent comments and duplicate bugs.

PLEASE admins and developers do something about this!!!

Comment 52

[Alex Monras]

Can we do something in order to let them know that this is not being addressed?
I think comment #39 above is more than right. Mac bugs are more likely to pass unnoticed because most Mac users don't even know they can file bugs. They should pay more attention to these...

Comment 53

[Shawn Wilsher :sdwilsh]

I'm going to reiterate comment 46 and point folks to the bugzilla etiquette page:
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I'm taking this bug, but no guarantees about it making Firefox 3.1.  Please don't post comments saying that it affects you, you want this fixed, etc. because it just wastes people's time who are working on the bug.

Comment 54

[Hawkeye King]

As an additional workaround- instead of installing an old version of Safari, you can also use IE for OSX 5.2 preferences to modify the temporary download location entry in com.apple.internetconfig.plist.

To do this workaround: swallow pride and open Microsoft IE.  Go to Preferences -> Receiving Files -> Download Options.  Set the desired directory.  Close IE.  Open Firefox.

Comment 55

[andreas.fischlin]

I believe the simplest workaround is to get the browser Camino (http://caminobrowser.org). Camino is small, the smaller sister of FireFox, and it doesn't hurt to have an additional browser available.  Use Camino's preference tab "Downloads" to set the global (system wide) preference for download folder ("Save downloaded files to:"). You can set this to any folder you like. You can even choose a folder that is used by OS X for temporary storage and profit from the fact that OS X will automatically cleanup that folder for you. That folder is the 'tmp' folder which resides in a normally hidden folder 'private' (in Unix notation: /private).

The latter is actually normally hidden in the Finder and you may have difficulties to choose it. Then you have two options: You either use another folder or you make that hidden, nifty folder visible for ordinary selection via the OS X standard folder choosing dialog. There are again several techniques to make that folder visible. The simplest is to use the Finders menu command "Go -> Go to Folder..." and then type "/private" into the appearing text field and press button "Go". The folder 'private" should open in an ordinary Finder window. You should see several folders within tha window, 'tmp' being one of them. Now you can make an alias from the folder 'tmp', for instance by Cmd-Option-dragging its icon to some other, visible folder. If such an alias resides in some normally visible folder, say your desktop, your home folder, or under Leopard your Downloads folder, you can see it always. Therefore you can also choose it via Camino's preferences. Once set you could even trash that alias. However, I keep this alias around. This way i can easily switch the preference anytime to another folder or again back to the 'tmp' folder.

Hope this helps to circumvent the problems discussed here.

BTW, see also bug #446291 for a discussion how to improve the preferenes in ThunderBird to make it clearer what ThunderBird's preference is actually good for.

Andreas

Comment 56

[andreas.fischlin]

For all who are familiar with Unix commands there is a very simple technique to make a tmp folder alias or even easier, a symbolic link to the hidden 'tmp' folder visible. Launch the application Terminal (in /Applications/Utilities) and type the following command (assuming you are using Leopard, Mac OS X 10.5.x):

ln -s /private/tmp ~/Downloads/tmp

Then you have a symbolic link 'tmp' in your Downloads folder that points to the hidden 'tmp' folder. Then you can easily switch the downloads preference to the Desktop, to the Downloads folder or to the 'tmp' folder anytime.

If you are using an older Mac OS X system, say Tiger, Panther or even older, you might want to create first a permanent Downloads folder in your home directory before executing above command. You can do that in the Finder or for Unix adepts above command would simply be preceeded by following Unix command:

mkdir ~/Downloads

Enjoy!
Andreas

Comment 57

[Mike Connor [:mconnor]]

pretty late to fix this for this cycle, not marking wanted, but a safe and well tested patch would be considered.

Comment 58

[andreas.fischlin]

Excellent news!
Andreas

Comment 59

[Shawn Wilsher :sdwilsh]

Attachment: v2.0

New approach.  We keep doing what we've always done on non-mac platforms.  On OS X, we dump it into the users download directory.  This basically copies the code from nsDownloadManager::GetUserDownloadsDirectory, but degrades to the default location if we hit errors along the way.

Comment 60

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Shawn, does that mean that even temporary files (for helper applications) will be saved inside the download directory in that way?

Comment 61

[Shawn Wilsher :sdwilsh]

(In reply to comment #60)
> Shawn, does that mean that even temporary files (for helper applications) will
> be saved inside the download directory in that way?
On OS X, yes.  This is what we always /tried/ to do, but failed quite miserably if you didn't use the default location.  I think that any other behavior changes should be done in a different bug.

Comment 62

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Shawn, as what I've noticed is that all temporary files don't get deleted after I close Firefox. Even when I have set browser.helperApps.deleteTempFileonExit to true. So it means that we will clutter the latest set download folder (which will not only be ~/Downloads) when applying the patch? If yes then it will be a major privacy issue.

Comment 63

[Dave Rothlisberger]

What's the privacy issue? The previous behaviour was that temporary files were saved to ~/Desktop (regardless of what you set the downloads folder to be). The temporary files were not being deleted before so no change there -- better to clutter ~/Downloads (with files you've chosen to download!) than ~/Desktop.

If Firefox should be deleting temp files and isn't, that's a separate bug (as Shawn indicated).

Comment 64

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Which means that the following described steps still work and temporary files will be placed furthermore within the specified temp folder?

http://www.hskupin.info/2008/05/22/temporary-folder-for-firefox-and-thunderbird-on-os-x/

Shawn, how close is bug 374184 to this one? Further shall I file a new bug for the temporary files issue?

Comment 65

[Shawn Wilsher :sdwilsh]

(In reply to comment #62)
> Shawn, as what I've noticed is that all temporary files don't get deleted after
> I close Firefox. Even when I have set browser.helperApps.deleteTempFileonExit
> to true. So it means that we will clutter the latest set download folder (which
> will not only be ~/Downloads) when applying the patch? If yes then it will be a
> major privacy issue.
That should be working - so that sounds like a different bug.  Please file it (and mark in-testsuite? because that isn't that hard to write an automated test for).

(In reply to comment #64)
> Which means that the following described steps still work and temporary files
> will be placed furthermore within the specified temp folder?
No, they will end up in your downloads folder, if set.  This has always been what we did, but then the download manager changed things, and exthandler fell behind.

On OS X there never has been a difference between temporary files and non-temporary files in terms of downloads.  They have always been considered the same.

If we want to change that behavior, I think we should file a new bug (bugs are cheap).

> Shawn, how close is bug 374184 to this one? Further shall I file a new bug for
> the temporary files issue?
I am of the opinion that that bug is INVALID because the report is not clear.  It should be closed and a new bug opened with a clear explaination on what exactly is wanted there.

Comment 66

[Nathaniel Virgo]

Hi guys

I don't understand what's happened here.  The problem (clutter due to files being saved on the desktop when choosing to open them with helper applications) and the obvious solution (put such files in /tmp) seem to have been spelled out very clearly several times.  So where does the reluctance to just do it come from?

(In reply to comment #63)
> better to
> clutter ~/Downloads (with files you've chosen to download!) than ~/Desktop.

Surely it's better to clutter /tmp with temporary files.  

They are not files you've chosen to download.  They are files you've chosen to open with another application.  "save" and "open" do not mean the same thing.  They do not do the same thing on other platforms.  Why do they have to do the same thing on OS X?  Cluttering "Downloads" with files you chose to *open* (and not to *download*) will be almost as annoying as dumping such files on the desktop, as it will make it hard to find the files you did actually want to keep.  "Downloads" should be kept for files you have actually chosen to save.

Comment 67

[Robin]

Hi,

(In reply to comment #59)
> New approach.  We keep doing what we've always done on non-mac platforms.  

I don't understand this - on non-mac platforms $TMP or $TEMP is used I thought (or a similar system temporary directory on Windows). No other platform puts temporary 'open with' files in the download directory.

The suggested fix would actually be a regression for me - since at the moment with workarounds described it is possible to get temp files and selected downloads to go into different directories. If I understand the proposed fix this would now be impossible - everything would go to Downloads.

Comment #35 explains that there is per-user temporary directory in OS X exactly for such use. Why can we not use that as a default value for 'open with' temporary files? It seems the closest match to the behaviour on other platforms.

In addition it would be nice to be able to select the download - personally I like the temporary files not to be purged every reboot.

I'm also not sure where the confusion arises - the original bug seemed quite clear:

from comment #2
"I'm asking that there be a *preference* for setting where the $TMPDIR is."

Thanks

Comment 68

[Nathaniel Virgo]

(In reply to comment #65)
> On OS X there never has been a difference between temporary files and
> non-temporary files in terms of downloads.  They have always been considered
> the same.
> 
> If we want to change that behavior, I think we should file a new bug (bugs are
> cheap).

To add to what I already wrote, I don't think a new bug would be appropriate.  This one is about the lack of a preference for where temporary files are saved, so if there is a lack of a distinction between temp files and saved ones, that clearly falls under this bug.

This bug has 33 votes and the proposed patch does not fix it.  A new bug will have 0 votes but the problem will remain, and we'll just have to wait for the votes to build up again before something gets done that actually fixes it.  Sorry if that sounds cynical but this bug's third birthday is on Wednesday so we've been waiting long enough already.

(but having said that, Firefox on OS X currently *does* treat temp files differently to downloaded ones.  It puts downloaded ones in a user-configurable folder but always puts temp ones on the Desktop no matter what.  All that needs to be done is to allow the user to change this directory from being the desktop to being somewhere else, such as an appropriate system temp folder.  Nothing new needs implementing other than the ability to change that preference from within Firefox)

Comment 69

[Fred Wenzel [:wenzel]]

(In reply to comment #68)
> This bug has 33 votes and the proposed patch does not fix it.

I agree, dropping temporary files into the Downloads folder instead of Desktop as the only measure to fix this bug is not sufficient. The aforementioned User temp folder would be a more reasonable default for sure. With this being the default, adding an option in about:config to change the setting if you really need to would suffice (and could arguably be a new enhancement bug to this one if you like).

Comment 70

[Jonathan Payne]

So, this is UNIX. Store the tmp files in /tmp. Personally, I like them all in the Downloads folder because then I know where to find them. Just because I let an application open the file it doesn't mean it's a temp file. I like to know where to go find them when I am done messing with the application.

The problem now is that you cannot specify a folder at all because it's ignored. If I can specify it as the Downloads folder, then I know where to go to find it later and/or delete it later.

But ANYTHING is better than dropping the files onto the Desktop. I can't think of a worse folder than the Desktop to plop little attachments.

Comment 71

[Fred Wenzel [:wenzel]]

Shawn: I don't think your patch was that bad (no need to pull it completely) -- how about instead of dropping temporary files into the Downloads dir, you just let it default to NS_OS_TEMP_DIR?

Comment 72

[andreas.fischlin]

(In reply to comment #70)
I consider the separation into downloads (save) and open with files as most useful and the approach to take to finally overcome these difficulties. This also means I opt strongly against a personal preference saying that this user likes the two categories to end up in the same folder. If that's the case, there is always the option to set both preferences to the same folder. However, for the majority of users who seem not to like this being the same folder, there would be no possibility to accomplish that. Let's not go behind what we already had, but where at least the cumbersome workaround as I have described it under Comment #55 can provide a solution. What is needed now is merely a preference setting that allows to control the preference for tmp-files that is already used now but that can't be controlled by the user unless he/she uses Camino or a special Safari version. If Thunderbird and Firefox offer such a preference setting we are set and the issue is resolved (for good).

Comment 73

[Andre-John Mas]

This ticket has been open for three years and no solution seems to have been implemented. 

In the short term it would be nice to at least keep the current functionality and simply allow an over-ride in about:config. This won't serve as the ultimate solution, but at least it will provide some peace.

Long term I think we need to base the solution on usage and file life-span. If the files remain long after Firefox has been quit then the downloads folder should be used, otherwise other options that come to mind include:
  - System defined temporary directory
  - ~/Library/Firefox Temporary Downloads --- This is based on the notion of Mail.app, which uses "~/Library/Mail Downloads"
  - ~/Library/Caches/Firefox/Temporary Downloads --- This is based on what Opera does
I looked to see what other occurrences of "temp" or "temporary downloads" folders that were created by other applications in ~/ and these are the only candidates that seem anywhere near suitable.

Having said all this I really believe that solution should be a combination of configuration property (about:config) and a suitable default location to be used as value.

Comment 76

[andreas.fischlin]

Why not using the /tmp folder maintained by OS X? Then the fix for this bug would be very simple to implement:  What we need is merely a preference setting that allows to control the preference for tmp-files. As a programmer I strive always for the simplest possible solution. 

Why is this solution the simplest? FF and TB use such a preference already internally, but the user has no control over it. And the troubles and many complaints by users (see also bug 286094, bug 446291, bug 374184, bug 243975, bug 238789) comes from this fact and that this internal preference defaults to the desktop or another globally determined download folder (e.g. in Leopard ~/Downloads). A ~/Library/Caches folder as suggested in Comment #73 needs a new cache empty functionality being added to FF and TB. Otherwise these folders will accumulate temporary files for ever. If all should happen automatically, then FF and TB need to have a complex algorithm deleting files older than a given period, say a month etc. In addition users might wish to have full control and you need to add a menu command that allows to delete the cache as this is the case with many browsers (Remember, I'm talking here not only of FF, but also of TB). This seems to me all to be unnecessary complex, particularly given the fact that this issue is open since 3 years! 

Thus I strongly opt for keeping it simple. Therefore I opt for the simplest possible solution that does the job: FF and TB offer a preference setting where the user can choose any temporary folder. That preference defaults to /tmp. The only thing which is needed to program is then minimal, a preference dialog to select a folder for the existing preference. With such a solution we are set and the issue is resolved for good. Then the workaround as I have described under Comment #55 becomes unnecessary. The workaround is cumbersome and may prevent many not-technically inclined users from using FF and TB under OS X (for details see Comment #55 and see also bug 286094, bug 446291, bug 374184, bug 243975, bug 238789).  

However, while doing that I would suggest one more thing. I suggest to add also a reset button behind the Choose... button. Its purpose is to reset that preference to the default /tmp if the user has set it to some other folder. Having such a reset function would be user friendly, since folder /tmp is hidden and can't be found via an ordinary folder selection dialog (see Comment #55 describing the workaround in more details).

Comment 77

[andreas.fischlin]

Hint for programmers:  On OS X /tmp is a symbolic link to /private/tmp:

# ls -l /tmp
lrwxr-xr-x@ 1 root  admin  11 Apr 15 15:56 /tmp -> private/tmp

Permissions are tricky and above output is not explaining all: Everyone has read write permission for that folder (under Leopard e.g. Read & Write permission is listed for all, i.e. system, wheel, everyone). Unix tradition being that all users can store temporary files there and the system will clean it up automatically.

Andreas

Comment 78

[Andre-John Mas]

With regards to comment 76, one issue of using /tmp is that it is not a folder on most user's radar, while anything in their home directory is. The issue of emptying a cache folder should be a non issue, since these files are considered temporary anyhow and we should surely be applying some sort of clean up routine on every platform? The clean up routine could be as simple as deleting any temporary files older than 1 day.

Remember currently the issue is that ~/Desktop is being used as the temporary folder and no clean up is being done here what so ever.

I am going to see whether I can find out from anyone on some of the Apple development mailing-lists if they can suggest anything, with regards to what is recommended.

Comment 79

[andreas.fischlin]

Why should use of /tmp be an issue? Apple is doing that themselves with Safari, i.e. pdf's viewed are stored there, despite having a cache folder in ~/Library. I'd say this is a good method to do this in OS X.

Andreas

Comment 80

[Fred Wenzel [:wenzel]]

Well, there is a per-user $TMPDIR in OSX, for exactly these purposes:

$ set | grep -i tmpdir
TMPDIR=/var/folders/Ku/KueKHwOaBcWIfIMsjDPCKk+++TI/-Tmp-/

Comment 81

[andreas.fischlin]

You're right. I overlooked this. Indeed it would be better to use that folder via environment variable TMPDIR.

BTW, /var/folders is physically /private/var/folders (link) and is as such besides /private/tmp.  I'm using /tmp, i.e. physically /private/tmp, since months as temporary storage location for ThunderBird. I have not encountered any problems so far. But I agree, it would be probably better to use $TMPDIR, since Apple is actually using that folder for temporary storage of files such as pdf files when Safari shows a pdf (Apple's native support for viewing pdf's handed over to Adobe Reader). I tested this now carefully.

Comment 82

[Andre-John Mas]

Having asked on the darwin-dev mailing list at Apple, using
  
 confstr(3) with _CS_DARWIN_USER_TEMP_DIR

would be a suitable approach. Another answer suggested

 FSFindFolder() in Folders.h (kDownloadsFolderType, kCachedDataFolderType, etc.).

Comment 83

[andreas.fischlin]

Please, not kDownloadsFolderType. That would bring us AFAIK back to square 1 and the flood of complaints from end users that temporary storage location would be the desktop by default would start up again.

Comment 84

[Andre-John Mas]

For reference here is the thread I started on the darwin-dev mailing-list:

http://lists.apple.com/archives/darwin-dev/2008/Oct/msg00057.html

with this post providing an interesting round up of the uses of the various locations:

http://lists.apple.com/archives/darwin-dev/2008/Oct/msg00067.html

Comment 85

[Till Korten]

I would vote for: _CS_DARWIN_USER_TEMP_DIR, since this would result in the same behavior as under windows and linux and make firefox consistent for all platforms.
Also, this is what safari does.
I would strongly discourage using NSDownloadsDirectory since this only works with leopard and would, in principle, result in the same problems (just in a different directory).

Comment 86

[diebuche]

With one of the later Firefox Updates the temp dir is now the Download Folder.
This might prevent a cluttering of the Desktop, but still People might want to be able to change it. I have my download dir set to a folder on another HD, because my boot volume is fairly small. But everytime I let FF open the downloaded file it saves it in ~/Downloads and not in /Volumes/External/Downloads
In 90% of the time, I don't click Open because I only want to temporarily use the file (eg. PDF) but I want to Open it now, but be free to use again later.
Thatfore I vote to let the user specify whether he wants his tmp directory to be /tmp or ~/Downloads or another Folder in cases like me.

I don't think adding an option at least in about:config would be hard, but it would make things easier a lot.

Comment 88

[diebuche]

I don't want to annoy you guys (since there are probably more important things to be fixed), but is anyone of you working on it?
It's been reported in 2005 the first time and it pretty much sucks for us endusers having to clean up those directories every time we open something downloaded.

Comment 89

[Rahul Abrol]

Attachment: unify platform code

since no one refuted comment #35, here's a patch for it.  it puts the mac code back in line with the other platforms.  occam's razor.

Comment 90

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Comment on attachment 356833 [details] [diff] [review]
unify platform code

Shawn, no idea if you are the correct person to ask for a review, but what do you think about the patch?

Comment 91

[Shawn Wilsher :sdwilsh]

Comment on attachment 356833 [details] [diff] [review]
unify platform code

There are a number of reasons why this is wrong:
1) It doesn't actually allow you to specify the location of temporary files (what this bug is supposed to be about)
2) Comment 35 probably wasn't addressed because it seems pretty clear that it is factually wrong after reading bug 191385 (see bug 191385 comment 5).

Comment 92

[Till Korten]

(In reply to comment #89)
> Created an attachment (id=356833) [details]
> unify platform code
> 
> since no one refuted comment #35, here's a patch for it.  it puts the mac code
> back in line with the other platforms.  occam's razor.

_Thank you_!!! I am convinced this is the best solution! Unless there is a very strong argument to treat mac special, I think the behavior should be the same on all platforms.

Way to go!

Comment 93

[Till Korten]

Just to clarify:
I think the reason why so many users complain about not being able to specify the temp dir is that the temp files clutter their desktop!

With the patch from comment #90 files that are viewed, not downloaded will not go to the desktop any more, but to NS_OS_TEMP_DIR, which is ~/Library/Caches/TemporaryItems. This folder is cleaned once every reboot (about 3 times a year for me) and not after firefox closes.

Of course, an option to configure this directory would be desirable. However this is quite a bit of code and therefore would take more time to make it into the stable tree.

In my opinion any folder is better than the desktop! And it is not that hard to just click save as... in Preview. That way you don't need to redownload the file.
Therefore I strongly suggest to go with Henriks Patch and put this argument to rest. If anybody wants to code a configure option for this, he is very welcome to write it after the issue with cluttering the desktop has been resolved.

But please don't spoil the solution for the cluttered desktop again by arguing which is the most mac-like way!

Comment 94

[Rahul Abrol]

(In reply to comment #91)
> 1) It doesn't actually allow you to specify the location of temporary files
> (what this bug is supposed to be about)

granted.  it's merely a step in the right direction.

> 2) Comment 35 probably wasn't addressed because it seems pretty clear that it
> is factually wrong after reading bug 191385 (see bug 191385 comment 5).

could you specify the error(s) please?  note that bug 191385 comment 5 was written six years ago when the code was rather different.

comment #93 sounds about right.

Comment 95

[Shawn Wilsher :sdwilsh]

(In reply to comment #94)
> granted.  it's merely a step in the right direction.
And so was attachment 337082 [details] [diff] [review], but people complained that it didn't fix the issue that this bug is filed for.  Please read comment 0.

> could you specify the error(s) please?  note that bug 191385 comment 5 was
> written six years ago when the code was rather different.
Sure, the code was rather different, but that's a non sequitur since we are talking about the expected behavior on OS X.  I just download a dmg from Safari, and it dumped it on the desktop (I'm on 10.4).  PDFs load in the browser, so I can't test with that.

> comment #93 sounds about right.
And that's not what this bug is about.

Comment 96

[Henrik Skupin [:whimboo][⌚️UTC+2]]

> (In reply to comment #94)
> talking about the expected behavior on OS X.  I just download a dmg from
> Safari, and it dumped it on the desktop (I'm on 10.4).  PDFs load in the
> browser, so I can't test with that.

On 10.5 the download folder is used by Safari for temporary files and not the desktop. That's a feature.

So one proposal:

Can't we add a hidden pref for another folder as a) the desktop (10.4) or b) the download folder (10.5)? If the pref and the given path exists use that folder otherwise NS_DOWNLOAD_DIR?

Similar like this behavior:
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2187

Would this be an option?

Comment 97

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Shawn, that means your patch wasn't as bad but only misses the chance to specify another folder?

Comment 98

[Shawn Wilsher :sdwilsh]

(In reply to comment #96)
> On 10.5 the download folder is used by Safari for temporary files and not the
> desktop. That's a feature.
Right, and in 3.1, we should be doing that too now.

> Can't we add a hidden pref for another folder as a) the desktop (10.4) or b)
> the download folder (10.5)? If the pref and the given path exists use that
> folder otherwise NS_DOWNLOAD_DIR?
That's essentially what this bug is asking for.

(In reply to comment #97)
> Shawn, that means your patch wasn't as bad but only misses the chance to
> specify another folder?
That patch uses whatever folder is chosen as the download location in the Firefox preferences.

Comment 99

[Nathaniel Virgo]

(In reply to comment #95)
> (In reply to comment #94)
> ... I just download a dmg from
> Safari, and it dumped it on the desktop (I'm on 10.4).  PDFs load in the
> browser, so I can't test with that.

If you chose to *download* it then putting it on the desktop is expected
behaviour.  But that's irrelevant - this bug is about what happens when you
choose to *open* it.  These are two different concepts!  If pdfs open in the
browser then try it with, for example, a movie file which does open in a
separate application.  You will find that it saves it to a temp folder, not the
desktop.

As one of the end users who's been complaining about this issue, I'd like to
say that I agree 100% with comment #93.  The reason we want to be able to
specify where temp files go is so that we can stop them from cluttering up the
desktop - so changing the behaviour so that temp files are put in a suitable
system temp folder, even if it's not configurable, would be a vast improvement
on the current situation.

Comment 100

[Shawn Wilsher :sdwilsh]

(In reply to comment #99)
> But that's irrelevant - this bug is about what happens when you choose to
> *open* it.
You are right about it being irrelevant, but you are wrong about what this bug is about.  Please read comment 0.

Comment 101

[takacs]

(In reply to comment #100)
> (In reply to comment #99)
> > But that's irrelevant - this bug is about what happens when you choose to
> > *open* it.
> You are right about it being irrelevant, but you are wrong about what this bug
> is about.  Please read comment 0.

Do you mean that the statement "[...]this bug is about what happens when you
choose to *open* it.[...]" is not in line with comment #0?

Comment 102

[Shawn Wilsher :sdwilsh]

(In reply to comment #101)
> Do you mean that the statement "[...]this bug is about what happens when you
> choose to *open* it.[...]" is not in line with comment #0?
How about I quote it so there is no ambiguity here:
> Expected Results:  
> It should have downloaded the file to a temp-files directory of my
> specification.

Comment 103

[takacs]

But he did chooose to open the file, his first reproduction-step was
"1. Under Prefs -> Downloads, set the action associated with PDF to "open""

So clicking the link should be equivalent of choosing 'Open' in the dialogue-window which would have appeared instead had he choosen a different setting for that filename extension.

Comment 104

[Robin]

From my perspective I am worried that the attachment in #90 would be a regression for me.

At the moment there are workarounds to allow one to specify the temp dir through a third party program (Camino, an old safari etc.) which work. With this change, I am not sure how it will be possible to specify the temp location (on other platforms one can change the TEMP environment variable, but I'm not sure where the NS_OS_TEMP_DIR directory specification comes from).

Since there still seems be a little confusion in the above comments on the 'open' vs 'download' front - this bug is about what happens when you 'open' a file - ie firefox downloads the file to a temporary location and passes it to an external viewer.

- Files that are downloaded (through save as etc.) go to the download folder. This works.
- Files that are chosen to be 'opened' rather than saved, either in a preference or through the pop up dialog, should be stored in a *seperate* *configurable* directory.
- Currently they are saved to a directory specified in an obsolute OS X preference, that can only be changed through using Camino or an old version of Safari.
- While defaulting to NS_OS_TEMP_DIR is sensible, it is not clear how this can be overriden, so to address the original request of this bug, a configuration option to manual specify it should also be included.

Comment 105

[Nathaniel Virgo]

(In reply to comment #100)
> You are right about it being irrelevant, but you are wrong about what this bug
> is about.  Please read comment 0.

I don't think so.  This bug is about not being able to specify where temp files are put, as comment 0 clearly states.  I said that the reason people are so concerned about not being able to specify the temp file location is that it results in desktop clutter.  Comment 0 mentions this as well: "When I quit, this file is still there, and still cluttering up my desktop."

Perhaps the confusion comes from a differing use of the term "open."  I am taking mine from the following Firefox user interface feature:

1. click on a file which can't be opened in the browser
2. a dialogue box called "Opening file.pdf" comes up with the following two options:
 - Open with [drop down list of applications]
 - Save file

This bug is about an issue that occurs when choosing the first of these two options, which is why I'm referring to it as "opening" the file.

Comment 106

[Rahul Abrol]

shawn, i now see why you pulled your own patch, but what happened to it?  why not file a new bug for it and get it landed asap if you don't want to expand this bug?

Comment 107

[Derek Jacobs]

Shawn pulled himself off the CC list. I think he's washing his hands of this problem?

When I first submitted a bug on this problem, back in 2004 (Bug 263830) I never thought it would take four years to fix. The patch rahul posted, in my opinion, would definitely do what I wanted to see going on 4 years ago. While, yes, it's not a configurable directory in the client (which is what Shawn was getting at in referencing comment #0) it would match the behavior safari now exhibits, if I'm not mistaken.

Comment 108

[Till Korten]

I agree that this bug is about adding a feature to be able to change the location where temporary files are downloaded. However this bug has been open for over three years now. The reason for this being that apparently users can't agree on a solution that satisfies everyone.

However, in my opinion the main problem is not satisfying everyone but resolving the issue, that Firefox clutters the Desktop as soon as possible.

Therefore I filed a new bug #473763 that proposes the following strategy: 
a) First and quickly resolve the cluttering the Desktop issue by using NS_OS_TEMP_DIR  instead of the Desktop. This will make Firefox behave consistently across all platforms.
A patch for this was already posted by rahul abrol: Attachment 356833 [details] [diff]

b) Resolve THIS bug by adding a configure option in about:config that enables
users to change the directory for files that are opened instead of downloaded.

In order to make this work, I suggest that as many people as possible vote for the new bug.

Comment 109

[andreas.fischlin]

It is amazing how much discussion this issue triggers (similarly with bug #238789 and many other bugs perhaps already rightly so or less rightly so considered to be a duplicate of this bug). Let me remind you of a few things how the situation actually is (I'm referring to the situation on the Mac; wait, don't stop reading yet if you are not much interested in Macs: Unless programmers more oriented to the Windows platform read this carefully, I fear we will never manage to resolve the issues discussed here). I make an attempt to clarify the situation:

- There is a workaround for the cluttering problem (see e.g. my comment #55 and #56) already available now

- Yes we have two concepts involved here, adding to the confusion (permanent vs. temporary storage) (see e.g. my comment #72). Many users and even some programmers seem to be confused because they don't know this (it's for sure NOT the uers's fault, however, IMHO). The two concepts are

a) Permanent storage folder (by default Desktop) can only be emptied by the user

b) Temporary storage folder (by default Desktop) can be chosen such that the system and/or TB (FF) empty it regularly. The user need NOT know where that actually is and most users don't know.


- Users complain because the permanent storage folder gets cluttered full by some unwanted, temporary files (this bug #311292 or bug #238789 etc.). Some users want to control the location of such a folder. Some ask for automatic cleaning up, others want to keep some files and argue against automatic cleaning up etc. A big mess because many do not know that TB (as well as FF) differentiate internally between permanent storage and temporary storage of downloaded files and/or attachments. The difference being: Permanent storage location is where TB and FF save any files the user explicitly wanted to save to disk and intends to keep. No system, nor TB (nor FF) interfere with these files. It's fully under the users control and responsibility. Temporary storage location is only used when the user wants to view an attachment. E.g. you double-click onto the attachment icon at the end of your E-mail. The system then needs to download nevertheless that file and needs to store it somewhere on the computer's hard disk. If that's the desktop, this can be perceived as being very annoying (clutter complaints). Mac OS X offers elegant solutions for the default location for such temporary storage. Many applications commonly in use on the Mac, e.g. Safari, use that very same technique and also differentiate the two concepts. One could argue Mac users are already used to them. If you open a link to a pdf only for viewing the pdf file is actually downloaded to such a temporary location only (/private/var/...). However, if you decide to actually download the pdf, because you want to keep it, then the file is downloaded to the permanten storage location. Under Mac OS X 10.5.x this is the so-called Downloads folder (~/Downloads). Under older Mac OS X systems this used to be the desktop (~/Desktop).

- On the other hand, we should be fully aware that it is also a fact that actually both concepts are already present in TB and they are even both controllable by end-users. This shows the main problem is that those controls are offered in a way, which is - I agree with the complaints - inacceptably difficult to understand and use. All in all very messy. 

- I strongly argue for retaining the two concepts at the end-user level as well as internally (for programmers). Even if some users have argued to merge them. The reason being that it is easy for a user, to set the two locations to the same folder (if we fix these issues for good, see below).

- I repeat, it is a fact that the folder used to temporarily store files/attachments is controllable by end-users. However, only in a cumbersome, almost hidden manner. You need other applications such as old, special Safari versions hard to find or as I found out Camino (for details see my comment #55 and comment #56). 

- I repeat, it is a fact that the folder used to permanently store files/attachments is controllable by end-users. It is accomplished by the preference tab for attachments. However, again this is done in a very confusing manner and introduces again a misunderstanding and confounding of the two concepts (my suggested solution for this: next point).

- I suggested a minimal solution (bug #446291, comment #22) for avoiding the current misleading preference settings allowing users to control permanent storage location. Current implementation causes confusion, since it offers a dialog that determines permanent storage location while at the same time allowing for specifying actions that are relevant only for temporary storage. But this difference between these two concepts is nowhere explained. Unfortunately that's exactly where I fear almost no progress has been made and actually programmers seem to fall back into reinforcing the very same problems with latest development efforts (see later discussions under bug #446291 and my comment #28; the latest TB implementation (version 2.0.0.19 (20081209)) has unfortunately completely ignored my suggestions for a solution). Solving bug #446291 properly might lessen the current debates around this bug #311292 and bug #238789)

- What is needed in addition to above improvement with preference setting dialogs is the following: TB (as well as FF) should introduce the control for the 2nd preference setting, i.e. the location for temporary storage.  If my fix (comment #55 and comment #56) would be so elegant, why would this discussion still be going on? IMHO it is not acceptable having to use on the Mac other applications such as old, special Safari versions or Camino to control this preference. It appears to me to be clear that a good solution calls for allowing TB and FF users to directly choose a folder of their preference for temporary storage. Or then use a system specific location, different from the one where by default permanent storage goes and that is automatically handled by the system correctly, i.e. hidden from user, cleaned up automatically (see also comment #78 to comment #85). 

- I argue moreover and regardless of response by programmers to above point: The default for temporary storage has to be different from the folder used for permanent storage. This is AFAIK currently not the case, since both preferences are by default set to the desktop. 

- I suggest to use as the new default for temporary storage /tmp or something similar (see comment #78 to comment #85).

- I suggest to use as the new default under OS X 10.5.x for permanent storage the user's Downloads folder (~/Downloads), under older OS X the user's desktop (~/Desktop).

Hope this all helps users (and perhaps even programers) to better understand the issues under discussion and to make real progress towards a solution. Let's make TB (and FF) be excellent applications, even on the Mac!

Comment 110

[Rahul Abrol]

(In reply to comment #106)
> shawn, i now see why you pulled your own patch, but what happened to it?  why
> not file a new bug for it and get it landed asap if you don't want to expand
> this bug?

i admit i was searching in the wrong branch.  shawn applied his patch several months ago (see bug #454242).

Comment 111

[Peter Gerdes]

(In reply to comment #109)

> - Yes we have two concepts involved here 
[snip]
> 
> a) Permanent storage folder (by default Desktop) can only be emptied by the
> user
> 
> b) Temporary storage folder (by default Desktop) can be chosen such that the
> system and/or TB (FF) empty it regularly. The user need NOT know where that
> actually is and most users don't know.
> 
> 

While I strongly agree that any solution is better than what we have now the issue isn't as simple as you suggest.  Indeed, your very choice of descriptions "Temporary" and "Permanent" storage folder showcase the difficulty of a good solution.

The real folders aren't Permanent and Temporary but
a) Files downloaded with an explicit save action.
b) Files automatically opened by applications on download.

The problem is this distinction in the browser does not map nicely onto the user's expectations or usage patterns.  If I download a .gz file and have the browser set up to automatically run a program to expand that file it ends up in b not a despite the fact that in terms of use it should end up in a.

> - I argue moreover and regardless of response by programmers to above point:
> The default for temporary storage has to be different from the folder used for
> permanent storage. This is AFAIK currently not the case, since both preferences
> are by default set to the desktop. 

Alright, so I'm using firefox for the first time and I download a .gz file or the .dmg file I downloaded last night but never got around to using where do I look for these files?  The permanent download directory obviously.  I can't find them there and I get frustrated.

> 
> - I suggest to use as the new default for temporary storage /tmp or something
> similar (see comment #78 to comment #85).

That's the worst possible option.  Cluttering up people's folder with mpegs or whatever is slightly annoying but at least it's useable.  Your defaults end up with .gz files or .dmg files and the like hidden where the user can't find them and worse where they may end up deleted on an unsuspecting user.

------

I think the right solution is to introduce a checkbox for each type of download in the Applications panel of the preferences.  This would let users select whether a file of that kind opened with the helper application would be considered a permanent download or a temporary file.  With sensible defaults this could actually make the distinction work.

Comment 112

[takacs]

> That's the worst possible option.  Cluttering up people's folder with mpegs or
> whatever is slightly annoying but at least it's useable.  Your defaults end up
> with .gz files or .dmg files and the like hidden where the user can't find them
> and worse where they may end up deleted on an unsuspecting user.

Actually, the fundamental difference between Download and OpenWith is that the latter is used for files that the user do _not_ want to keep for long. Otherwise one would for example choose Open from the download manager after it has been downloaded. Think of what people actually use the OpenWith feature for. My view is that it's mainly used for files like torrents, playlists (mostly for accessing a stream broadcast) and documents (like pdf and doc that you just want to read though your browser can't handle them on it's own). All of these are file the user does not want to keep and perhaps most importantly, does not expect to when they use that feature (except for mac users, thanks to this bug).

Comment 113

[andreas.fischlin]

(In reply to comment #111)
I think you misunderstand several issues and your criticism to the solution I'm proposing does actually not apply. The rationale:

It appears you may not fully understand the behavior of the applications TB and FF. It is AFAIK exactly as I described. I can also assure you that I have tested this very carefully, notably within TB, and had actually to spend lots of time in doing that, despite the fact I am an experienced programer. But I agree, it is difficult to understand from the end-users viewpoint. A main reason why we have this messy situation and that much debate. 

It appears to me you make also further mistakes. With my suggestion you do NOT get the difficulties you describe. It's exactly the other way round. Let's take TB: You receive an attachment of a pdf file. If you want to save it to disk, it will end up exactly where the user searches first according to your expectation, i.e. in the permanent storage location. If you wish to open it directly by double-clicking it, it will end up in the temporary location. It won't clutter your permanent storage location. If you decide to keep it, you can still save it to disk, perhaps customize the behavior by using such an action for a particular type of file or simply move the icon from the E-mail to any folder whatever. Let's take FF: You come to a site offering a dmg for download. You click on the link, the dmg is downloaded exactly in the location you think users will expect it in, i.e. the permanent storage location (configurable by FF preference). However, if you open a linked file, say a pdf, for viewing only, the file should only go into the temporary storage location and it will not clutter up your permanent location.  I do not think I create any problems with my solution. 

BTW, I am working with TB by making good use of this behavior since months with success. I am using exactly those preferences that I suggest to use by default. TB can already do all this as I describe in my comment #109. The configuration is just cumbersome (see comment #55 and comment #56), hard to understand (see comment #109), and many users seem not to be aware of the fact that TB (AFAIK FF) distinguish already internally the temporary and permanent storage (as appropriately also stressed by comment #112).

Hope this clarifies that the counter-arguments of comment #111 to my proposal (comment #109) do actually not apply.

Comment 114

[Steve Godun]

All this back-and-forth is, from a non-programmer's perspective, absolutely shocking.

This seems to be a textbook example of too many people getting caught up in minuscule details to an extent that they're missing the big picture. To wit: The preference in Firefox is, "Save files to (location)". This is an absolute; when I see "Save files to (location)" I translate that as "Save all files that Firefox downloads to (location)" as do, I suspect, everyone who uses Firefox (and isn't part of the development process).

We know that this only works for files that aren't opened by an external application. Therefore, the function is broken in Firefox. It isn't a question of whether it's a temporary file or not, or whether it's handed off to another application or not, or whether it should go into /tmp or not. What happens to the file AFTER it's downloaded is irrelevant. It's the downloading process that's important. The file should be downloaded to the user-specified location REGARDLESS of what the user wants to happen to the file AFTER it has been downloaded. This is not happening and this is what should be addressed.

Perhaps it's because I'm not a programmer but I don't understand what all of this debate is about. This is a simple issue: All of the files that users specifically download via Firefox need to go in the specified location. Period. That's it.

This reminds me of something.... A little over three years ago in my hometown a boy on a skateboard got hit by a car at a blind intersection. For nearly 14 months the township council held debate after debate over what to do about the intersection. Some people wanted to put a traffic light up, others wanted a blinking light, others wanted to completely overhaul the intersection, others wanted a bike path installed, others wanted pedestrian crosswalks installed, etc. In that 14 months there were two more similar accidents there, one involving a pedestrian and the other with a bicyclist. Then someone who lives near that intersection took a piece of plywood, painted it yellow, wrote "BLIND INTERSECTION - PROCEED SLOWLY" in black, and nailed it to a tree at that intersection. Since that sign went up there have been ZERO accidents there.

Right now, from my perspective, we're in the township council meetings. Someone needs to take some plywood and paint and get to work. Please. Thank you.

Comment 115

[andreas.fischlin]

(reply to comment #114)

The big picture is comment #109

That may not be obvious to you, but please, I believe this gets close to a bit an unfair criticism to claim that we are here only discussing minuscule details. Programing is in the end quite complicated and unless everyone, i.e. the end-user community as well as the programmers understand the big picture AND the details, I'm afraid we will just continue discussing in circles and not making any progress as we did in the last 4 years. In that respect I'm afraid your cross-road example is not well taken. My conclusion from all this is that we need to understand the problem first, or we continue failing in resolving it as we do since years. 

My big effort comment #109 does actually attempt to summarize as comprehensively as possible all the many discussions, including your comment, that are sent back and forth since years on this and numerous related issues (cf. this bug #311292, bug #238789, bug #243975, bug #286094,  bug #374184,  bug #446291, and bug #454242 - perhaps there are even more discussions going on, many seem not to be aware of the other). I wish we could really make some progress and stop going in circles. Moreover, I'm even afraid we may have reached here even some limit of what open source can do.

BTW, AFAIK nothing is broken in FF the way you describe it. It seems to me you are simply having difficulties - as many others too - to understand how it is meant. You only confirm my statement that users are confused.

Finally, I'm not part of the development process. True, I have decades of programing experience, I have been teaching computer science at universities, but I am here using my skills only by trying to help: To consider the viewpoint of end-users as well as those of programmers as comprehensively as possible. I'm hoping the programmer's understand the problem (based on comment #109) and help to find a solution, so that end-users will then also understand how to use TB and FF. A well designed user interface can make a huge difference. That's the only thing I see in which we need to actually move forward in order to put this seemingly endless debate to rest. The task is first with the programmers, i.e. to fix the user interface in the way as I describe in comment #109. Afterwards the end-users will be able to understand the issue. Perhaps then one could talk about minuscule improvements again. Right now it is quite an issue for all those end-users who suffer under clutter or struggle otherwise with attachment or downloaded files etc. I've read many comments claiming that it is no go for using TB at all on the Mac platform. A minuscule detail only?

Please let's stop the discussion here and hope that programmers of TB, where I see the issue to be of particular relevance, draw the conclusion from comment #109 and hopefully fix the problem, finally. It's overdue, AFAIK since 2004!

Comment 116

[Robert Strong (they/them - no direct email)]

Most likely Core -> File Handling but moving over to Toolkit -> Download Manager so the toolkit sub-module owner can make the call

Comment 117

[Shawn Wilsher :sdwilsh]

(In reply to comment #116)
> Most likely Core -> File Handling but moving over to Toolkit -> Download
> Manager so the toolkit sub-module owner can make the call
Yes, yes it does belong there.  I don't know why it ever got moved out in the first place...

Comment 118

[Henrik Skupin [:whimboo][⌚️UTC+2]]

For now I can give a short and really helpful note: If you don't wanna see temporary files cluttering your desktop while running Shiretoko, open about:config and set the pref "browser.download.folderList" to '1'. That will download all temporary files to the system download folder. It also applies to nightly builds of Thunderbird 3.0 (called Shredder).

Please stay tuned for the final fix. I'll triage the remaining things now, so we will have it hopefully fixed for the final 3.1 release.

Comment 119

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, this bug has been fixed by the check-in of the patch on bug 454242.

The selected default download folder from within the Firefox preferences is used now to store temporary files and downloads. That is the same way like it is handled in Safari. If you want to still get asked where any downloads should be stored, just check the appropriate option. The last selected download folder will be independent from the given default download folder.

Anyone who is willed to have a try please download one of the latest 1.9.1 nightly builds: http://tinyurl.com/atyngl

I hope that it will fulfill everyone's needs.

Comment 120

[Nathaniel Virgo]

Hi, I'm sorry Henrik but this bug is not fixed by applying the patch in bug 454242.  This bug (311292) is about not being able to specify the location of temp files; the patch in bug 454242 just puts them in the downloads folder.  This is inconvenient for me, and for other users who read a lot of pdf files on OS X, because I don't want to keep most of the files I open.  That is why this bug is asking for an option to store temp files in a temp folder.

Comment 121

[andreas.fischlin]

Indeed. Please read my Comment #109, only if you do all what I describe there is this really fixed.

Comment 122

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sorry, you are right. Let's open again and wait for the outstanding fixes in that area which will happen within the next days. When everything will be fixed for the permanent storage, the patch on this bug shouldn't probably too complicated.

Comment 124

[Tom Roberts]

New use case for which this bug fails:
History of computer and Firefox:
 1. purchased with Tiger installed
 2. installed Firefox, upgraded several times
 3. upgraded OS to Leopard
 4. upgraded Firefox, now 3.0.6

NONE of the suggested workarounds work on this system, temp files all go to the desktop. 

On a similar system that was purchased with Leopard, temp files go to Downloads (VASTLY better). I don't remember if I did any of the workarounds, but think it started that way.

I am VERY frustrated with my inability to get Firefox to stop cluttering up my desktop.

Comment 125

[andreas.fischlin]

Have you tried the workaround I described under Comment #55 using Camino?

Comment 126

[Paul]

I did try your workaround in comment #55 and it was incredibly easy and worked wonderfully!  Thank you for solving this issue that has "bugged" me for years!

I would also like to add that I agree with what you describe in comment #109 as the solution.  Since it seems this bug has been open for many years and no one can decide can we at least have a option hidden in the about:config menu to set the temporary download folder location?  This way we can continue to discuss ad infinitum the nuances of a dialog box and how to present this to the users, while the advanced users will at least have a solution without be forced to use another program to set the download location.

Comment 127

[Tom Roberts]

(In reply to comment #124)

My comment was in error about no workarounds working for that system. I repeated the steps of comment #30 and discovered that the DownloadFolder preference was still present, so somehow I screwed up the first time. Deleting it and restarting Firefox, it now puts temp files into my Downloads folder, not the desktop. 

That's good enough.

Comment 128

[Jeremy Leibs]

I just got a Mac on Sunday and this problem has been driving me crazy since I installed firefox.  I spent far too long searching for an option inside of firefox itself, since I couldn't even fathom this kind of atrocity on file management would still exist at this point in time.

First of all, Andreas, thanks so much for the Camino suggestion in comment #55... that's at least enough to keep me sane while this issue gets resolved.  Sadly, that has other ramifications on the rest of the system.  For example, now the "save file" option in safari goes to the tmp directory... equally unacceptable.

Secondly, I don't understand why this is so difficult for people to agree on and fix.  The comments in #109 seem mostly dead on.  Though I 100% agree, I do see there are some semantic naming issues that need to be addressed.  Still, we ONLY have two kinds of behaviors... it is clear we need to separate them and give control over BOTH:

 1) (Optional) default "save file" location.  This is clearly already addressed in preferences and works just fine.
 2) Default "open with" storage location.  This is what it is.  This is what the dialog asks people and should be clear to any user that has downloaded something.  There is no implication of what it should be used for.  Some users will choose something like "/tmp" others might choose the same "Desktop" or "Downloads."

There is a COMPLETELY SEPARATE issue that I saw raised about non-intuitive behavior relating to the choice of a user to use temporary storage vs. non-temporary storage for something like a .gz or .zip file.  Half of this issue is not firefox's problem in the first place.  It's easy enough to change the preferences on something like stuffit expander to prompt for a destination rather than unzipping in place.  However, that said, it would be both nice, and possible for us to add override functionality according to mime-type.  Firefox is already storing preferences by mime-type of default activity in terms of "open with..." or "save file."  It should not actually be difficult to store one extra field there in terms of a specific location to store the file if it is opened with an application.  Then, a user who really cared could set up .gz files to always go to "downloads" instead of "tmp."

Comment 129

[S P Arif Sahari Wibowo]

As some already said, I think the folder for external viewer's files should be separate from default download ("save file") folder. For external viewer's files either use the "cache" folder or use a separate preference altogether.

Why? Think about it. The default download folder has several other options that control it: whether to prompt, whether specified or use last ones (at least in SeaMonkey). This means the default download folder is not necessarily where I want all files went. For instance it may just base folder for several sub-folders, and user want those downloaded files go to the sub-folders. User may not want anything fall into the current / default download folder.

In the other hand, external viewer's files in cache folder actually make sense: when you click a link to a HTML file to view it, you don't expect the HTML file to show up in the download folder, do you? It should stay in cache folder. The same with viewing PDF file. If user want to save a HTML file, user can do it after viewing it using File->Save page as, well the same with PDF (most PDF viewer allow user to "save as" the page).

Therefore put external viewer's files in cache folder make sense. Alternatively, an entirely separate preference should be acceptable.

Comment 130

[andreas.fischlin]

AFAIK (having hacked into low level preference settings as used by TB and FF) there are already two such preferences distinguished. The problem is, the user has not full control over those preferences. I believe the comment #129 merely confirms some of the aspects/motivation behind this bug as I described in my workaround (comment #55) and the solution concept I propose (comment #109).  

In other words, could you S P Arif Sahari Wibowo perhaps agree with the spirit of comment #126 by Paul? That may actually possibly help the programmers to go ahead with what I suggested in comment #109.

Comment 131

[Mason]

Those in this thread that are arguing that this might not be a bug are remind me of the oil merchants who argue that global warming might not be caused by humans.

Comment 132

[klein.mike]

So I created a Bugzilla account just so I could post a comment.

Quite frankly I find this back and forth debate quite absurd. Has anyone thought about the reason this is only an issue on Mac and not any other platform? It's because the behavior of Firefox on Mac differs from that of Firefox on Windows or Linux. For a lot of new Mac users (and some existing ones) it's really annoying that files that were supposed to be opened temporarily are permanently saved in the Downloads folder. Just because Safari does it does not make it right.

That is the reason this issue has arisen.

As for the solution, I think the idea of the user manually having to choose a temporary file location is abhorrent. However, I don't see the problem with having an about:config property, as a boolean, that simply specifies whether temporary downloads are saved to the Downloads folder or to the Temporary Files folder.

It might even be a nice perk for Windows and Linux users who'd rather have the Mac behavior.

Think it over. But for god's sakes please don't take another 4 years doing so.

That is all.

Comment 133

[andreas.fischlin]

Yes, there is quite some absurdity in this. In particular also in light of the following facts: I believe I have provided a very clear and comprehensive explanation and proposed very clearly solutions, i.e. Comment #109. Perhaps you may want to amuse yourself further with  Bug 446291 comment #43, where I list many other related bugs, all surrounding in fact the very same problem. Given the arguments, my fear is that this issue is really reaching the limits of what open source can accomplish. I mean here it clearly starts to fail.

Comment 134

[S P Arif Sahari Wibowo]

Why this bug is only in Mac?

So, I went through the reading of all references in these bugs, including to other related bugs such as bug 191385, bug 302433, and bug 374184; apparently the difference was deliberate and for historical reason: apparently long time ago, Netscape (everybody still remember Netscape, don't you?) made a usability study and concur that Mac users doesn't like browsers to drop downloaded files - even temporary - in temporary folder - apparently because many users don't even know where the temporary folder is. Not sure how long ago the survey was, but if it was done in Mac OS classic era, probably somewhat understandable. Furthermore there was an Apple HID guideline that point out that download folder should be queried from Internet Config.

Following the specific of each platform is commendable; however, IMHO the way it was done is incorrect. Instead of forcing everybody using that platform to follow the platform way instead of the application way, users should given a choice; e.g. a simple checkbox in the download preference: follow Mac way or Mozilla way for external applications opened files, will solve this issue nicely.

Things went very bad when Safari 3 went out, which lost the ability to change that Internet Config parameter for download folder (or probably just decide to use different configuration / parameter). At that time there is no "official" way to redefine where those files should go, and in many case it goes to Desktop - the default download folder in Mac OS - which has been my experience.

Should be noted as well that when I first move my configuration file from Linux to Mac OS X, I did not remember having this issue. As I remember, it only become a problem once I started to use SeaMonkey 2 (alpha / pre-release). Was somehow SeaMonkey 1.x determine which folder to drop external applications opened files from the configuration file? If yes, then this behavior was GOOD! The platform-specific option as I said above should be made so people who know how to copy configuration file is not surprised by change of behavior (i.e. lack of that configuration item in the configuration file should be consider as "follow Mozilla behavior").

Comment 136

[andreas.fischlin]

A reply to comment #134. 

Thanks for these ideas and yes, you give some explanations with respect to older operating systems on the Mac. 

However, I belive the issue is not Safari 3, the issue is TB (and FF) not allowing the end user to control a preference they internally use plus the fact that TB (and FF) continue confusing end-users because of an otherwise poorly designed user interface (e.g. bug 446291). 

BTW, in comment #55 I describe a simple method to circumvent bug 311292, using Camino for a function that neither TB nor FF offer. This shows also that Camino did at that time what TB or FF should have done since a long time, but still don't! If I'm not mistaken, this bug 311292 remains unfixed since 2005!

On your proposed checkbox: I also describe a fix for TB and FF on this bug 311292 and related issues in comment #109 together with a dialog design I offered under bug 446291, attachment id=383512 (https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512). All issues addressed in bug 191385, bug 238789 and then bug Bug 9309, bug 286094, bug 374184, bug 243975, bug 454242, bug 480899, bug 467577, bug 485201, bug 371608, bug 473763, bug 302433, some IMHO only allegedly fixed would go away at the same time, if my suggestions I give in comment #109 would be followed through. Then and only then, all the bugs I list here could be considered resolved.

Now, given my arguments (comment #109) I do not see how your checkbox is helping much. It only comoplicates matters further and might even confuse users more. The advantages of my solution (comment #109) are: It is 
- elegant, 
- simple to implement (requires only a relatively simple fix in the user interface, bug 446291, attachment id=383512 - https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512 )
- easy to understand (which should be the case even for programmers ;-) ).

To the last argument: It is easy to understand, since it supports a simple user model. That user model is: There is a temporary storage location and a permanent storage location and that the end-user has control over both by preference settings. Unfortunately, programmers of TB and FF seem not to understand the resulting relatedness of this bug 311292 with the user interface, that would be needed to support this simple user model (e.g. bug 446291, comment #50). They consider now to have fixed bug 446291, and consequently missed out on an opportunity to fix also this bug 311292 (and many of the related ones, see above) at the same time. A pity!

To sum up: I fear users will continue being confused about the functionality of TB and FF, will continue complaining (e.g. bug 191385 allegedly fixed, bug 473763 allegedly resolved, bug 238789, bug 454242) and waiting for a solution for this bug 311292 (including related issues not really resolved or with insufficient progress such as bug 446291 (bug 286094), bug 9309, bug 480899 and to some extent even bug 374184). For how long more?

Comment 137

[Robin]

I have just upgraded to Firefox 3.5 and unbelievably the situation actually seems to have got worse for me! 

I was previously employing the work around described to change the temporary files settings to a seperate tmp dir. Now it seems all pdf's I open go to the downloads directory. We do not want this to happen! The problem is that it is now impossible to seperate documents (in my case mostly PDFs) that I have opened in passing from those which I wish to keep. This does not happen on any other platforms.

Please, give us a way to specify the location for files that are 'Opened' rather than 'Saved'. On other platforms I could control this usign the TMP enviroment variables (I forget exactly which one) 

In the meantime, I would appreciate if anyone finds a new workaround to manually set the 'open with' temporary directory to update here.

Comment 138

[andreas.fischlin]

I fully understand your problems, but why I'm not more surprised to hear such bad news? ;-) Again I can only refer to my comment #109 together with my dialog proposal for preference settings (https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512). Following these suggestions through would offer a solution that would solve all these issues for good. 

One final question: I guess you have tried my circumvention of this problem under comment #55, right? Please confirm. Thanks.

Andreas

P.S.: In case you tried comment #55 circumvention and it does not work, then I can only cross my fingers and hope that some of the programers will start listening and not cause us to stop using FF and TB. Given the experience you describe, I will not dare using a new TB (my current version being 2.0.0.22 (20090605) unless I see an equivalent remedy as I describe under comment #55.

Comment 139

[Robin]

Yes, the method in comment #55 is what I was refering to. This does no longer work in Firefox 3.5 - 'open with' files are now hard coded to go to the standard download location. So the best I've found so far is to set the Download directory to where I want 'open with' files to go, and then select "Ask every time" in preferences for downloads (so I specify manually every time I save something). It is a pain, but better this way since I open many more files than I download. (Although of course it is a serious regression from firefox 3.0)

Comment 140

[andreas.fischlin]

I see. Thanks, but you confirm my worst fears. Oh my, sigh! :-( :-( :-(

So I will no longer update for newer versions until these issues are resolved. I hope not having to abandon TB, since this is what it means for me if this issue is not resolved sometimes in the future. Users are now complaining on this for years. If I'm stuck with the current version of TB 2.0.0.22 (20090605) I might be stuck with it for years until it ceases working for software erosion reasons. A nightmare.

Comment 141

[John Gentilin]

Please, please put control of where temporary files are stored with the user. 
If not directly on the preference UI then in the custom preference settings..

I have read some bizarre support threads and I think this one tops them all..
There have been a lot of suggestions and I don't think any one will satisfy everyone, but as long as you have a few workarounds a custom options, you will be able to satisfy more users.
 
Is there any way this can be customized with a plug-in ??

I am a long time TB user on Windows who just switched to a mac and I fear that I will be switching to another email program soon... I need to open hundreds of emails each month with voice mail messages that just need to play in quicktime and have no need to be stored on my Desktop or clutter my download directory.

Comment 142

[andreas.fischlin]

I couldn't agree more. But I believe I have made suggestions for a solution that suits all needs, because it offers full flexibility. See my comment #109 together with my dialog proposal for preference settings (https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512). Following these suggestions through would offer a solution that would solve all these issues for good.  

Have you tried my circumvention of this problem under comment #55?

Comment 143

[John Gentilin]

I thought I read somewhere in the 5 year long thread that comment #55 had
stopped working.. After reading the previous post I downloaded Camino and
gave it a try . It worked and was stored my wav file attachments in /temp, 
ye ha..

but not all is well today, a few days after I applied the change, I was 
going through my voice mail's and after I closed all the apps down, my 
desktop was wall to wall wav files... I have not touched a system setting, 
I went in to Camino and the setting had reverted to my Downloads dir, and Thundirbird was saving to my desktop event thought the preference setting 
is /temp..

What the heck... besides having to deal with no home / end keys, this Thunderbird attachment behavior is killing me..

I guess its time to leave Thunderbird behind and find something else...

-John Gentilin

Comment 144

[plecto]

(In reply to comment #137)
> I have just upgraded to Firefox 3.5 and unbelievably the situation actually
> seems to have got worse for me! 
> 
> I was previously employing the work around described to change the temporary
> files settings to a seperate tmp dir. Now it seems all pdf's I open go to the
> downloads directory. We do not want this to happen! The problem is that it is
> now impossible to seperate documents (in my case mostly PDFs) that I have
> opened in passing from those which I wish to keep. This does not happen on any
> other platforms.
> 
I quote Robin.
Please solve thi issue.
> Please, give us a way to specify the location for files that are 'Opened'
> rather than 'Saved'. On other platforms I could control this usign the TMP
> enviroment variables (I forget exactly which one) 
> 
> In the meantime, I would appreciate if anyone finds a new workaround to
> manually set the 'open with' temporary directory to update here.

Comment 145

[normlegit]

The Open/Save dialog box sets a very specific expectation for the user.  There is a radio button denoting two choices: open or save.  Keyword is "or."  The current behavior is:

if (open) then save file *and* open file
if (save) then save file.

This is incorrect behavior, there are a couple of ways to fix this bug:

-  Grey out/disable "save file"
   The file will be saved no matter what, no reason to call this out explicitly.  At this point "open file" can be made into a checkbox, because that too is an option.

-  If the user chooses to "open" the file, save it to a temporary directory and open it.  This is desirable and in accord with other browsers as well as FF on other platforms.

Comment 146

[andreas.fischlin]

Dear normlegit

I doubt you understand the issue fully if you write what you just did. There is a save and there is a open (permanent vs. temporary saving for only viewing) and both have their own preferences and are otherwise to be kept completely separate for the user. TB should offer a command that saves permanently attachment(s) and then offer a dialog or store always at the same location (FF) depending on preferences. The other command is for viewing an attachment and no dialog should be involved and only the SEPARATE preference where to store the temporary file should be used internally. The user sees nothing of this at all, no dialog unless the handling of the attachment is not defined (but that's again something else). Unless you distinguish those different cases along all levels involved the issue will remain, the complaints will continue to come in, and people like me will stop using Thunderbird or FireFox for any attachment handling or downloading (I have stopped using Thunderbird entirely). I've given up, since I feel programmers of those application have never seriously listened and seems never to have tried in earnest to understand the real issues. In case you should be interested what I have been contributing in hours of thinking to these issues, here once again some references:

Please see comment #109 together with my dialog proposal for preference settings
(https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512). Following
these suggestions through would offer a solution that would solve all these
issues for good.

Andreas Fischlin

P.S.: But as I have said, I stopped using this software. A clear case of completely failing open source. Reason being it is now years and years of user feedback and solution offering by programmers like me (e.g. comment #109), but things have only gotten worse, since the circumvention method I offered in comment #55 seems to have stopped working (see some of the previous comments). BTW, I have not tested this myself because I am tired of testing when there is such a slim chance that something might improve.

Comment 147

[normlegit]

(In reply to comment #146)
> Dear normlegit
> 
> I doubt you understand the issue fully if you write what you just did. There is

andreas,

I did not stumble upon this bug by accident, I found it because I was looking for it.  That predicates some level of understanding, no?  The second option I've presented, e.g. "This is desirable and in accord with..." is what you describe in the rest of your post.

Sorry to hear you're no longer a user.  If you scroll to the top you can remove yourself from the CC list for this bug.

Thanks.

Comment 148

[andreas.fischlin]

Dear normlegit

Sorry, if I may have sounded too critical, I for sure don't want to sound offensive nor getting personal. and I am very grateful for your efforts. That's also why I am still interested and won't stop listening to what you and oter programmers are doing and won't desubscribe. I am truly in favor of open source, despite my disappointing experience with TB. I just stopped using it because of the buggy attachment behavior. I'm dealing with thousands of E-mails all the time and need a very reliable program to do that. More and more people send unfortunately only attachments and an otherwise empty E-mail. Thus attachment handling becomes more and more important. Unfortunately TB is plaguing me with the same problems since years, all explained to any degree of detail in my posts mentioned above. Who knows, perhaps you are able to fix this problem. You would need only to implement it exactly according to the specifications I wrote and all would be fine. Then I might be using TB again. ;-)

Andreas

Comment 149

[klein.mike]

I've found that there is actually a rather simple, if rather non-obvious, way around this bug. In Firefox, go to Preferences->General (in Thunderbird go to Preferences->Attachments) and click the radio-button next to "Save files to", then click the "Choose..." button and select the folder where you want to store *temporary* files when they are opened. After that, select the radio-button next to "Always ask me where to save files". The next time you choose to save something, just navigate to your downloads folder, save the file, and after that it will always remember the last folder that you saved to. *But* if you choose to "open" a file, it will always default to saving it in the folder you specified in the Preferences dialog. Problem solved.

Comment 150

[andreas.fischlin]

Dear Mike,

Thanks for finding this solution. This corroborates only what I am have been saying since a long time, TB and FF have already the needed preferences internally (comment #109), they merely don't allow the user to control them both from the preference settings (comment #109). You obviously found now a trick to accomplish that without resorting to Camino or old Safaris, even TB (or FF) can do it.

And then, how about implementing it in an obvious way, i.e. to make all this understandable for ordinary users at the GUI? Please see comment #109 and my preference dialog design https://bug446291.bugzilla.mozilla.org/attachment.cgi?id=383512. Then the problem would be solved for good, as I am suggesting since a long time. Users would stop complaining and continue using TB on Macs. 

Andreas

Comment 151

[Ty Brewer]

(In reply to comment #149)

UNBELIEVABLE!

I've not used Firefox on a Mac for the last 2 years because of this issue. I'm continually reading .pdf files. They would always end up in my Downloads folder (which is normally my desktop), when all I wanted to do was read them temporarily. Before this fix, it was way too unwieldy having all those .pdf files in that folder.

This fix takes care of it!

Thank you, Mike, for taking time to understand the issue and find a resolution!! I'm astounded at how long this issue has gone on unresolved and how long it has taken for someone to actually "get it."

Thank you, thank you, thank you!


> I've found that there is actually a rather simple, if rather non-obvious, way
> around this bug. In Firefox, go to Preferences->General (in Thunderbird go to
> Preferences->Attachments) and click the radio-button next to "Save files to",
> then click the "Choose..." button and select the folder where you want to store
> *temporary* files when they are opened. After that, select the radio-button
> next to "Always ask me where to save files". The next time you choose to save
> something, just navigate to your downloads folder, save the file, and after
> that it will always remember the last folder that you saved to. *But* if you
> choose to "open" a file, it will always default to saving it in the folder you
> specified in the Preferences dialog. Problem solved.

Comment 152

[M. Moose]

Its extremely helpful that we now have a way to automatically separate temporary files from files that we want to keep, but the problem is not entirely solved because the temp folder is not automatically emptied on exit.  The ideal solution would eliminate any need for manual cleanup of temporary files.  Why cant Firefox for Mac work the same way it does on other platforms?

I dont want to be a complainer, but if you say this issue is resolved when its not, Mozilla developers may regard that as an excuse to ignore the problem and it might never be fixed properly.  The user should not have to create a temp folder to view files in external applications.  They should not even need to know where the temp folder is: all of that should be automatic.  But this becomes possible only when the temp folder is automatically emptied on exit.  The current behavior is not user-friendly at all: its a big nuisance to those who are computer literate, and utterly incomprehensible to those who are not.  

Every Mac user I know has asked for an explanation or complained about this at some point because it does not make sense.  The behavior of Mozilla products should be consistent regardless of the hardware platform, to the extent that is possible--the same way it is with extensions.  This aspect of Firefox is just plain wrong and it still needs to be fixed.  A work-around that 1% of Mac users will manage to find is just not acceptable.  This is an example of bad software design and it is unquestionably Mozillas greatest public relations blunder on the Mac platform.

Comment 153

[andreas.fischlin]

I fully agree.

May I remind you, though, that what you are saying is also contained in my major contribution on this issue, i.e. comment #109 (more than 1 year ago, sic). I suggested there the full solution for this issue, including full software specification and dialog design, but it seems the programmers contributing to FF and TB are not digesting this to the extent necessary. A pity! :-(

As a consequence I still no longer use TB nor FF.

Andreas

Comment 154

[Eric]

Please consider acting on this request, everyone that I know who uses FF on OS X is annoyed by this behavior. Pretty please :)

Comment 159

[steinar]

This thread is somewhat absurd.

First of all, it is five years old.  Bugs are still being filed on the same topic, repeatedly (but they are all being marked as duplicates, so nothing happens).  In fact I counted 22 bugs that are marked as duplicates of this one.  This bug has 83 votes, I'm not a developer so I don't know, but that seems sizable to me.

The technical situation has been changed somewhat due to some patches being made, but the end result for a "new" user has not changed.  By "new", I mean any Mac user who has installed TB with no previous configuration.

When you OPEN an attachment, a copy is saved to your desktop.

This is confusing, cluttering and it KEEPS PEOPLE AWAY FROM THUNDERBIRD.

Please, guys.  What needs to be done to fix this behavior?  Is anyone taking note that people are not using TB because of this?  What can we do?

Comment 160

[Mike Beltzner [:beltzner, not reading bugmail]]

I suspect a working patch, and less advocacy which really serves no purpose towards a solution to the issue at hand, is what's required.

If there's no clear user experience/interface decision made (I honestly can't tell) then add uiwanted to the keywords field.

Comment 161

[andreas.fischlin]

May I remind you, that an easy solution would follow from my comment #109 (now almost 2 years old). Perhaps it helps if I repeat what my full design for a solution in essence boils down to: It would only need to finally bring the hidden preference to the user interface so that users gain control over it (for any details see comment #109).

Comment 162

[steinar]

I do not have the time or knowledge to provide a patch.  I simply feel that this bug is a lot more important for Mozilla than the attention it gets.

How do I add uiwanted (or anything else) to the keywords field?

Comment 163

[Thomas C. Kral]

I have been having the same problem with Thunderbird 5.  Opening a file leaves a copy on the desktop.

I seem to have stumbled on an easy fix, albeit somewhat counter-intuitive.

Because I like to choose my save location, I did not associate the default save location as where the files being opened would be placed. when I realized the association the fix be came apparent.

The fix is to go into the attachment preferences and click the radio button to choose the always save files in this location.  Then browse to a folder that you want the files to be placed, (I chose a folder on the desktop), then click on the button that lets you choose the save location, and close the dialogue.

When you want to save an attachment, Tbird asks, but when I open a file it gets placed in the save folder.

I suspect that using the about.config file one could direct the files to the TEMPDIR for the OS which would be cleaned out regularly but I have not tested this.

Hope this helps someone

Comment 165

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Given that those downloaded temporary files still remain on disk after closing Firefox on OS X we have a privacy issue here. Those not deleted files can contain secret information like credit card billings which could easily be accessed by others on that account. Especially when Spotlight is enabled and those files have been indexed meanwhile, you will get them listed. 

Given that I also can't find feedback from UX I kindly would like to request an ui-review so we have a clear decision and can hopefully come up with a patch.

Comment 166

[Robin]

With respect, I think introducing the problem of a possible security issue with temporary files is not deleted only clouds this particular issue further. This bug regards Mac specific temporary file behaviour - namely that it is not possible to specify a directly for files that are 'Opened' rather than 'Saved'. On other platforms, for example, this is controlled with the TEMP or TMPDIR environment variables or similar. 
If you are worried about temporary files being deleted, this is an issue on all platforms and perhaps should be filed seperately as such. I think most of us watching this bug would prefer to first have the mac specific issue fixed to bring behaviour on that platform in line with all others before worrying about further changes to functionality. (I would certainly not want my tmp files deleted out of my control).

Comment 167

[andreas.fischlin]

May I remind you, that an easy solution would follow from my comment #109 (now 3 years old). Perhaps it helps if I repeat what my full design for a solution in essence boils down to: It would only need to finally bring the hidden preference to the user interface so that users gain control over it (for any details see comment #109).

In the mean-time I also offered a workaround, comment #55 and comment #56.

Otherwise I can only say that this bug demonstrates: Amazing how well open source can fail!  ;-)

Andreas Fischlin

Comment 168

[John Hopkins (:jhopkins)]

You may find the OpenDownload^2 addon helpful in the meantime:

 https://addons.mozilla.org/en-US/firefox/addon/opendownload-10902/?src=ss

I didn't see a way to override the download location that this addon uses, but it does use a temporary location.

Comment 169

[Jonathan Renpening]

I know it's been a lot of years and this bug is still on TB 24.0.1, Andreas Fischlin's solution is the best I have read among tons of comments but I would really like to see this implemented right, is there any plans on addressing this bug?

Jonathan Renpening

Comment 170

[Frédéric Harper]

I would like to know too as it's still in 24.2.0.

Comment 171

[Larry Xiao]

24.5.0

Comment 172

[No1Cares at Mozilla.org]

Thunderbird is pretty much dead, so those who have been holding your breath waaaaay too long already, don't.
http://techcrunch.com/2012/07/06/so-thats-it-for-thunderbird

Like Eudora before it (and before their "official" transition to this - lol!), I gave up on TBird years ago and suffer with Apple Mail.  Know what?  It ain't so bad.

In the meantime, I second Mr. Fischlin:
"Otherwise I can only say that this bug demonstrates: Amazing how well open source can fail!  ;-)"

Comment 173

[Fred Wenzel [:wenzel]]

(In reply to [e-mail] from comment #172)
> Thunderbird is pretty much dead

That's silly (not true, anyway), and out of scope here. Please don't keep "+1"ing a bug that's already almost 200 comments long.

Comment 174

[gregorprivat]

Trying not to be offensive, but i guess people would stop "+1"ing if this was resolved some day...
Or at least someone would close the bug if it will not be resolved...
I for myself still use TB on Mac and use some workaround (can´t remember what i did exactly, a few years later) that at least doesn´t clutter up my desktop, but it means that i can´t preview any attachments without saving them first and opening them from finder... :-/

Comment 175

[LornaHen]

I decided that it seemed unlikely that it hadn't been fixed, so simply removed whatever version I was on, and reinstalled a freshly downloaded current version of thunderbird instead of working with the version that had been upgraded from version whatever.
Works fine for me now.

Comment 176

[[e-mail]]

I can't believe that this bug is still not fixed after almost 10 years.

It makes Thunderbird almost unusable for most people trying to use it on a Mac.

I have tried numerous of the supposed fixes and none work for me on Maveriks.

There is currently NO decent email solution for a Mac (Mail.app is completely useless, and Outlook has too many faults to even think about it).

It would take very little work to make Thunderdird the foremost Mail app for macs.

I have voted and encourage everyone do so.
I'm sure that there are far more than 107 affected by this serious bug

Comment 177

[Darren]

For the record, this workaround gives me the behaviour I expect (saves opened-but-not-saved files to /tmp and deletes them on quitting Thunderbird). However, it's still really only useful if you also have Preferences -> Attachments set to 'Always ask me where to save files':

In the config editor (Preferences -> Advanced -> General -> Config Editor (button)), set these three preferences:

browser.download.folderList=2
browser.download.dir=/tmp
browser.helperApps.deleteTempFileOnExit=true

Comment 178

[__Pat__]

I find it hard to believe that an annoying bug keeps hundreds of posters busy (also note the many duplicate posting of this annoying behaviour) while it would take less than an hour in dev time to fix this. Can you simply set another default for the temporary location to save to? Why do you access a Safari setting to determine this location in the first place? It's a useless browser anyway.

Comment 179

[Jason]

Found this listed as a duplicate to the same behavior in Thunderbird, which just started to exhibit this behavior for me a couple of weeks back. Would love a fix.

Comment 180

[David]

(In reply to Darren from comment #177)
> For the record, this workaround gives me the behaviour I expect (saves
> opened-but-not-saved files to /tmp and deletes them on quitting
> Thunderbird). However, it's still really only useful if you also have

> Preferences -> Attachments set to 'Always ask me where to save files':
> 
> In the config editor (Preferences -> Advanced -> General -> Config Editor
> (button)), set these three preferences:
> 
> browser.download.folderList=2
> browser.download.dir=/tmp
> browser.helperApps.deleteTempFileOnExit=true

Coming back to mac after 5 years away. Astounded to find this bug is still here!!

Thanks to Darren for the workaround though - seems to do the trick!!

Comment 181

[Steuard Jensen]

Question for bsmedberg: Why was this assigned to Product: Firefox? Unless I'm really overlooking something, most of the discussion here has been focused firmly on Thunderbird attachments.

Comment 182

[Michael Hannemann]

@Steuard: If you go up to the first comments from 2005, this certainly started with Firefox.  Comments seem to indicate it applies to both.

Comment 183

[Matt]

Javi, If you were unable to assist in the Thunderbird bug on this subject,  can you offer some assistance in the toolkit bug here.

Comment 184

[:Paolo Amadini]

The user experience team assigned to overhauling the downloads experience in Firefox discussed this topic some time ago. The conclusion is that this issue will be tackled as part of a bigger redesign in bug 1270405. Sadly there are no engineers assigned to that particular project anymore, but as the triage owner of the Firefox File Handling component, I don't think it makes sense to keep this old bug report open, because the design goes in a different direction. In the past ten years, Mac OS has also changed significantly and the user expectations have likely changed as well.

We don't have a Bugzilla component for File Handling that is shared with Thunderbird anymore. If the Thunderbird project wants to do something different here, it should be addressed in a Thunderbird component. I do recommend filing a new bug, as I don't think the patches previously discussed here will be applicable anymore.

Comment 185

[Intenditore]

Oh men... This still isn't resolved 15 years later.
Srsly?

Comment 186

[Intenditore]

I think it's overall design flaw specific to Mac version. Why are temporary files stored in one huge pile in Downloads? On Win it's always in TEMP folder which is pretty logical. I highly dislike the way it's implemented on Mac and can't get the reason. It should be fixed for sure

Comment 187

[Matt]

(In reply to Intenditore from comment #186)

I think it's overall design flaw specific to Mac version. Why are temporary files stored in one huge pile in Downloads? On Win it's always in TEMP folder which is pretty logical. I highly dislike the way it's implemented on Mac and can't get the reason. It should be fixed for sure

You are welcome to hold whatever views you like, but posting in a closed bug report is not in the slightest chance of actually changing anything. The decision was based on the very emphatic demands really of some Mac users. Reading this bug and Bug 191385 makes it pretty clear that Mac users have expectations and when they are not met they take it very badly, even if their expectations are illogical. I suggest you file a new bug if you actually want to see change, referencing these old bug with a request that the issue be re-examined. You might also want to post in the Thunderbird UX mailing list if Thunderbird is your interest (This being a Firefox bug, I am just guessing) and see if anyone else thinks like you. https://thunderbird.topicbox.com/groups/ux