Closed Bug 191385 Opened 22 years ago Closed 17 years ago

Temporary files downloaded to ~/Desktop

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: martin, Assigned: law)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126

Under Mac OS X, when Mozilla downloads a file to open with a helper application,
the file is saved in the user's Desktop folder. Of course, this clutters the
desktop. 

For example, try downloading a PDF, telling mozilla to use Acrobat as helper
app. You will later find the PDF on your desktop. 

Under linux, those files are quite nicely stored in /tmp or equivalent. This
should be the expected behaviour. 

I supposed this would be configurable in prefs.js, so I grepped prefs.js for
'tmp', 'temp' and 'Desktop'; but I failed to find anything useful. I could not
find anything browsing through the preferences GUI. 


Reproducible: Always

Steps to Reproduce:
It should use the OS default temp directory.
Summary: Temporary files downloaded to ~/Desktop → Temporary files downloaded to ~/Desktop
Desktop _is_ the default temp directory on MacOS, last I checked (both Classic
and OSX).

Simon, is that correct?  If not, could we fix our dir service provider?
Making temp files go into the final download folder was a deliberate change for
mac; it fixed issues with running out of space in /tmp, and gives users a better
view that the browser is actually doing something during the download. It would
be just a small step from here to actually not doing name salting...

sdagley may remember the reasons for putting the temp files in the download
folder better than I.
We do name salting for a reason....  We _do_ drop the salting once the download
completes (at least on mac), even if we're opening in a helper app.  Precisely
because of the issues you discussed.

Note that the user doesn't exactly need feedback here -- we put up a progress
dialog or download manager during the download....
Besides what Simon said being 100% correct...

Most Mac users have no idea where the /tmp directory is nor do they like things
they just downloaded and viewed to be mysteriously deleted when they quit
Mozilla.  That's why we download to the user specified download folder and why
we don't delete files handed off to helper apps as the Windows and *nix builds
do.  This behavior is not going to change on Mac.  I once 'fixed' the latter for
Windows and *nix but was told to make it act the way it had been before.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Steve Dagley,

with all due respect, I have a few points to make from the point of view of a
mac and unix/linux user who uses Moz on MacOS X as daily productivity tool
(among other things).

I think this bug is relevant and deserves to be fixed because: 

- We are not talking about files the user chose to download, but files the user
wants to 'view'. This includes email attachments that don't display inline
(PDFs, etc). 

- Normal usage such as reading technical specs (PDFs) online and opening email
attachments with openoffice clutters the desktop. After every workday, I usually
remove a dozen or so files from my desktop. 

- On a mac, the desktop is where drives appear. Every once in a while, I
accidentally unmount a network drive when deleting said files. 

- This is not the standard behaviour of a mac app; compare with IE and how
various email clients handle attachments. The end-user never sees the file
(probably stored in tmp, or in ~/Library/appname/tmp). 

- It is not standard behaviour of *nix apps (under any WM) nor of Windows
apps... and notably on both platforms, moz follows the platform conventions afaik

- This behaviour is not configurable -- not even by editing prefs.js manually or
setting an environment variable (afaik).

 
I do not care what the behavior is for Windows and *nix apps.  I'll also venture
the guess that your background is primarily *nix with OS X now making the Mac an
appealing platform for you.  While you may be used to the *nix behavior of files
being tossed into /tmp and periodically scavenged, "traditional" Mac users
aren't.  They don't like it when the several megabyte PDF file they downloaded,
and you make a false distinction between downloading and viewing, mysteriously
disappeared when they quit Mozilla.  That's why the Mac version of Netscape has
never deleted temp files.  That Mozilla briefly did it was simply due to the PC
centric person that implemented the helper dispatch code not knowing what the
expected Mac behavior was.  And when Mac users started complaining it was fixed
and it will NOT be changed back.  If you don't like cluttering your desktop with
downloaded files simply change your download folder - it's done from the
Internet pane of the System Preferences app under the Web tab.  Make it /tmp if
that's what you really want.

P.S> Unless you've installed the PDF Viewer plugin Mac IE most certainly does
download files such as PDFs that are handed off to helper apps - look in the IE
Download Manager window sometime.
Hmm, I don't suppose we could make this a configurable option in the
preferences, with the default behavior being the current behavior?
Steve,

touche! you have guessed my background right. And I was wrong regarding the
behaviour of IE Mac (which does the same thing Moz does).

Apologies.  

I have also checked that Mozilla  follows the settings in the control panel you
mentioned. It does; shame on me for not knowing it. 

One minor issue is still unresolved in my mind, and it is the fact that mailnews
follows the same behaviour. I am not sure if this is desirable -- Apple's own
Mail.app keeps downloaded attachments in a directory in ~/Library, pretty much
like Eudora tends to do. 
MacIE offers an option to download the file to either a temporary directory (and
this option was available even in MacOS 9 and earlier) or to the download
folder. Besides, I have changed my download folder from the Desktop to a regular
folder but it is still cluttered with mainly pdf, QT-files and (uck!)
Office-files, all file types I much would have preferred they would be dealt
with the MacIE way. Maybe this is because I usually prefer external applications
rather than plug-ins to handle files like this, but I guess I am not alone in
considering the pdf- and QT-plugin to be very much inferior to their external
viewer counterparts.

Ooh, and my 'background' is classic MacOS even if I am (was) a CS-student.
However, this doesn't change the fact that when I see a good solution I want it
implemented in Mac OS X as well.

Just make it an option and you make a lot of people happy. Besides, if you use
the plug-in, the file is stored in the cache and sooner or later deleted. I
think it is consistent with that behaviour to store the files in the cache or
/tmp even when they are viewed with external applications.
I am a longtime Mac-only user (1987-1998 or so) and I don't buy the argument that Mac-users aren't used to have temporary-files stored in locations that are deleted regularly.

I have never met a Mac-user that is not annoyed with the cluttered desktop. Furthermore, if a downloaded file disappears, you still have it listed in your download manager. And MacIE had support for temp-dirs; you could specify on a filetype basis whether you wanted to store the file in the download folder or in a temp-dir. I have never seen any complaints about this behaviour. Mind you, a few years ago, MacIE was the default browser and the most used browser in Mac OS (X)
See bug 302433 how to change the temporary location and automatically delete these files on exit of Firefox/Thunderbird/SeaMonkey.
I have filed a new 'summary bug' for this bug and for bug 302433

See (and vote for) bug 374184
reopening due to bug 302433 comment 29

even though a user can change which directory helper application files are downloaded to, they can't do so without also affecting safari.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Normally, one would file a new bug in this situation.  Certainly if you want any of the people working on this stuff now to notice.  This bug is in the wrong product, has an incorrect assignee and QA contact, and has all sorts of only semi-relevant comments...

Please do file a new bug on the right folks.
Status: NEW → RESOLVED
Closed: 22 years ago → 17 years ago
Resolution: --- → WONTFIX
Boris, see comment #13. Hopefully, that is what you are looking for.
This bug is not resolved and should actually be marked as a duplicate of bug #311292
(In reply to comment #19)
> This bug is not resolved and should actually be marked as a duplicate of bug
> #311292
This bug is in fact resolved (as WONTFIX), and it is not a duplicate of bug 311292.
I do not call WONTFIX as really resolved and I wish to point out that the issue behind this bug is still quite and issue (see e.g. bug 311292, comment 134). Therefore I suggest to leave this bug as resolved, but mark it also as a duplicate of bug 311292. Assuming bug 311292 will possibly once be resolved. I still hope my solution as I suggest it in bug 311292, comment 109 will be followed through (but read also bug 311292, comment 134).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.