Closed
Bug 191385
Opened 22 years ago
Closed 17 years ago
Temporary files downloaded to ~/Desktop
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
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:
Comment 1•22 years ago
|
||
It should use the OS default temp directory.
Summary: Temporary files downloaded to ~/Desktop → Temporary files downloaded to ~/Desktop
Comment 2•22 years ago
|
||
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?
Comment 3•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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....
Comment 5•22 years ago
|
||
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).
Comment 7•22 years ago
|
||
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.
Comment 10•22 years ago
|
||
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.
Comment 11•19 years ago
|
||
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)
Comment 12•17 years ago
|
||
See bug 302433 how to change the temporary location and automatically delete these files on exit of Firefox/Thunderbird/SeaMonkey.
Comment 13•17 years ago
|
||
I have filed a new 'summary bug' for this bug and for bug 302433 See (and vote for) bug 374184
Comment 14•17 years ago
|
||
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 → ---
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 15•17 years ago
|
||
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
Comment 16•17 years ago
|
||
Boris, see comment #13. Hopefully, that is what you are looking for.
Comment 19•15 years ago
|
||
This bug is not resolved and should actually be marked as a duplicate of bug #311292
Comment 20•15 years ago
|
||
(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.
Comment 21•15 years ago
|
||
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).
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•