374184 - Please mimic MacIE's download manager/behaviour

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[db]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

This is "summary bug" for bug 302433 and bug 191385.

Please mimic MacIE's download managers behaviour where you, based on mime-type could decide whether you wanted to store a downloaded file in a dedicated download folder or a temporary folder. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[db]

Attachment: Screenshot of some of MacIE's download options

Comment 2

[db]

Attachment: More screenshots from MacIE

Comment 3

[db]

Attachment: More screenshots from MacIE

Comment 4

[db]

Attachment: More screenshots from MacIE

Comment 5

[db]

Attachment: More screenshots from MacIE

Comment 6

[:Gavin Sharp [email: [e-mail]]]

It would be useful if you would describe in more detail the actual feature that MacIE has that you'd like us to emulate. "mimic MacIE's download manager behavior" is a pretty broad request.

Comment 7

[db]

That is why I linked to the two other bugs.

Basically, determine the download behaviour (dl, handle internally, handle using plugin, dl to tmp dir and open using external app) depending on the mime type.

Comment 8

[Till Korten]

I am having the same problem so I would like to clarify and maybe some of the developers could have a look at this.

The problem is, that on Mac Os, whenever I click on a file on the internet (like a pdf or movie file) it is downloaded to the desktop and stays there. This is especially annoying if you read many pdf documents but only decide if you want to keep them after reading them. So effectively after using firefox for a couple of days your desktop is completely swamped with junk. 

This makes the desktop absolutely unusable for files you want to keep because they will often accidentally fall prey to cleaning operations.

There is no way to change this behavior except the undocumented option browser.helperApps.deleteTempFileOnExit=true.
and even this option does not really solve the issue because it only deletes the files after closing firefox, which, on a mac, happens very rarely since closing the last window does not close the program. Many users even do not regularly shut down the system but use the standby instead. That way it happens that I do not close firefox for 2 weeks or so.

The argument for this behavior was that mac users want it that way due to a survey conducted by someone from netscape years ago. Well, I don't know any mac user who wants this behavior, but I know many who do not use either firefox or their desktop because of this issue (our institute is a mac only institute, so i know many mac users).

Apparently firefox uses the systems temp folder which defaults to the desktop and as far as I know there is no way in mac os to configure this folder.

I (and many people I know) would be extremely grateful for an option to configure this and tell firefox to use a different temp folder.

Comment 9

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

(In reply to comment #8)
> Apparently firefox uses the systems temp folder which defaults to the desktop
> and as far as I know there is no way in mac os to configure this folder.

As I see you are German. So you shouldn't have a problem to follow the instruction I made on my blog:

http://www.hskupin.info/2007/03/11/temporare-dateien-bei-firefoxthunderbird-unter-mac-os-x/

That should move the temporary directory to your preferred location.

Comment 10

[Till Korten]

Thank you for your quick reply,

Sadly the fix you suggest in your blog (for everyone else: changing the download folder in safari) only works with safari 2.x not any more with safari 3.x!
So now there is no way to change the download temp folder in mac os x! (at least none I know apart from downgrading to safari 2.x and changing it there)

Comment 11

[Till Korten]

I found a DIRTY solution and posted it here:

http://forums.mozillazine.org/viewtopic.php?p=3220730#3220730

I also found out why the safari setting does not work any more:

Apple now uses safaris OWN PROGRAM SPECIFIC setting instead of the system wide one.

So much for the programming guideline!
I hope that this serves as an argument to reconsider using the system wide setting which in fact is not a setting any more but a constant since there is no way to SET this setting any longer!

Comment 12

[Andreas Lange]

It seems that Safari 3 moves from using the default download directory to a Safari-specific setting. That means that there is no way longer to configure the system setting that Firefox (and other xpcom-based products) use. 

In OSX <=10.2, this setting was available in the system preferences, in 10.3 it was moved into Safari and now it seems gone completely. A bit ugly if Fx3 relies on this still.

Should this bug be morphed to regard ability to specify a tmp download directory in a better way, is there already a bug for that or should we file a new one?

Comment 13

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

See the following URL for an explanation how applications under OS X should interact to get the internet config values:

http://developer.apple.com/documentation/Carbon/Reference/Internet_Config/Reference/reference.html

"Mac OS X applications should employ Launch Services and System Configuration for managing Internet preferences. In Mac OS X, Internet Config calls through to these newer APIs. Using them directly increases your application’s efficiency."

Should we use Launch Service directly? Do we get the download folder specified in Safari 3? Otherwise we really should give the users at least a preference to override the value. Josh, what would be the best way?

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/mac/nsInternetConfigService.cpp&rev=1.43&#445

Comment 14

[andreas.fischlin]

Above comments make a mess by confounding several issues. To help the  programmers (BTW I am also quite an experienced programer) I try to clean up a bit the many things said:

1) By default on a Mac OS X system the location to save donwloads to is the desktop.  This system wide predefined behavior can be changed.  It is a good philosophy to have such a folder be specified in an application specific manner.  Some of above comments merely refer to the fact that some users didn't like the default download location (desktop) and didn't know how to change that.  Safari allows to change that, ftp clients like Fetch allow to do that, Firefox allows to do that, Thunderbird allows to do that (but it doesn't work due to bugs) etc.

2) The problem with Thunderbird and older versions of FireFox are or were, respectively, that they have or still do not honor the settings of their own preferences (as of this writing still the case with Thunderbird, version 2.0.0.9 (20071031) ).  FireFox as of 2.x is fine and does honor the preference "Save files to" (Preferences > Main).  However, Thunderbird does still not fully do that and uses still the system wide defined download folder (desktop or whatever you have defined on your system).  Although someone stated that common program code ought to be used for downloading by FireFox and Thunderbird, there are clearly still differences.  My testing of Thunderbirds behavior while downloading attachments did not allow me to fully understand why in some cases the folder specified in the preferences is honored and sometimes it is not.  If it is not, still the previously system wide defined folder is used.  If it honors it's own preference, then the attachments end correctly up in the folder as browsed by the button "Browse" in preferences "Attachments". Not honoring its own preference  settings is in my view clearly a bug.

3) Thunderbird ignores the settings "Ask me where to save every file"  unless an action is set to "Save to disk". This is in my view a mistake,  given the text states "Ask me where to save every file". Maybe, if users  really should favor that behavior (I don't) then the text of the  preference should at least be altered similar to this:

      "Ask me where to save files that are to be saved to disk"

4) If Thunderbird has been configured to an action that opens an  attachment with a specific application, say ".doc" files with Word, then  Thunderbird unfortunately still ignores its own preference where to  download files and uses the folder as given by the system wide set preference. That is quite a  nuisance in some cases and I believe this to be a bug of Thunderbird. This  is a major reason why more than half of my attachments get corrupted by  Thunderbird. I would really like Thunderbird to finally honor the settings  of its own preference. If you specify a folder with preferences "Save all  attachments to this folder:" then any attachment downloaded (regardless  whether you subsequently open it with an application) or whether TB merely  downloads it to disk (without asking), then that folder and no other  folder should be used. I have reported this bug of Thunderbird (earlier on  also for Firefox) several years ago. Fortunately, for Firefox this was  fixed and all downloading works as specified by preferences. Unfortunately  for TB this bug has still not been fixed.

5) Behavior of Internet Explorer was still different.  I also agree that this was the most convenient mechanism.  Why?  The difference is that for every file type (extension, mime type) one could specify whether the file would be displayed within the browser by a plug-in, merely saved to disk, or the user would be asked each time where to save it to disk, or tempoarily saved to disk (most user won't even notice, since a temporary storage place would be used, e.g. /tmp ) and immediately opened by any application specified. Since all these  preferences could be given on a per file type basis, there was no  confusion as in case of Thunderbird where a global preference "Ask me  where to save every file" as an alternative to "Save all attachments to  this folder" are offered in combination with type specific actions. Thunderbirds philosophy is unclear, difficult to  understand by users and obviously programmer's as well. I clearly would  favor very much IE's approach. It is the most flexible one and even the easiest to understand.

Whatever the choice of the programmers of TB is going to be, I wish at least the serious bug as described under point 4 will soon be fixed. I hope also point 2) and 3) will  be addressed too. Ideally, all would be done as in IE (see point 5).

Hope this clarifies a bit the obvious confusion.

Andreas Fischlin

Comment 15

[Till Korten]

To Andreas comment paragraph 2):
Firefox does NOT behave correctly (does not honor the download directory set in its settings) in the following case (similar to what you describe for thunderbird in paragraph 4): If you choose open with... instead of save to disk, the file will always be permanently saved to the Desktop (OS X system default download directory which cannot be changed anywhere anymore as of safari 3.x). So basically firefox uses the desktop as a temporary floder which the user has to clean up by hand!

There is an undocumented setting in firefox which will delete these files when firefox is closed but since closing the last window does not close firefox in OS X, this rarely happens and is no solution to the problem.

I do suggest, as has been suggested before, that choosing open with... either saves files in the default download directory set in firefox (safaris behavior) or in a temporary folder (windows and linux behavior). My preference would be the latter but both cases are much better than the current behavior.

Comment 16

[Chris Walter]

In case it is useful to the developers:

I followed the instructions here:

http://discussions.apple.com/thread.jspa?messageID=5666281&#5666281

and deleted com.apple.internetconfig.plist in
~/Library/Preferences .

after this Firefox 3 beta used the download directory that I set with Safari.

This file was never recreated, so perhaps this is something left over from a previous version of Firefox or Safari which overrides the expected behavior.

After I made this change things worked as expected for me.

Comment 17

[andreas.fischlin]

All this should of course not be necessary. You should be able to simply use Firefox' preference and set the folder which you wish to use. Period. Then you should be done and Firefox should honor the folder you have set with "Save files to" (Firefox preference, tab Main).

Andreas Fischlin

Comment 18

[realgrouchy]

(my point 1) 
After poring through the many confusing bugs and comments in this post and in related bugs/comments/linked pages, I voted for this bug because I would like to change the folder in which Firefox saves files when I select the "download > open with" option. (Please let me know if I'm misinterpreting the bug)

I've enabled the delete-on-exit option through about:config, but I'm hesitant to follow any of the other suggestions because it's unclear whether any of them would enact the change I want. (My Safari "FireFox downloader" is apparently v3, so I can't use it to change the global settings).


(my point 2)
(In reply to comment #14) 
> 1) By default, on a Mac OS X system, the location to save downloads to is the
> desktop.  This system-wide predefined behavior can be changed.  

(my point 2a) 
It isn't clear at all to me how or where this can be changed. If you're referring to the Safari option, then (i) FF should not rely on settings that can only be configured in other browsers, Apple specs be damned, and (ii) it no longer works in Safari3 (justifying point i!)

(comment #14 continued)
> It is a good
> philosophy to have such a folder be specified in an application specific
> manner. 

(my point 2b)
I agree

(comment #14 continued)
> Some of above comments merely refer to the fact that some users
> ... didn't know how to change that. 

(my point 2c)
I disagree with this summary. I think all the users knew how to change the download directory, but are frustrated that the "open with" directory is not also configurable (either to use the same target as the default download directory, or to specify it independently)

(comment #14 continued)
> Safari allows to change that, ftp clients like Fetch allow to do that,
> Firefox allows to do that, Thunderbird allows to do that (but it doesn't work
> due to bugs) etc.

(my point 2d)
Okay, now things are beginning to lose meaning by using ambiguous terms. By "that" in this sentence, you are referring to the targetted download folder. But by "download", you are referring only to when files are downloaded, and not when they are opened by helper applications. I apologize if I have made the same point many times here.


(my point 3)
(In reply to Comment #16)
> After I made this change things worked as expected for me.
Chris, since so there are so many different behaviours and misbehaviours being reported, could you please specify what change in behaviour you are referring to when you say "things worked as expected for me"?

I don't want to follow those steps unless I am confident it will make the correction that I desire (outlined in my point 1)


Thanks.

Comment 19

[Tyler B]

Has any progress been made on this bug?  I don't know if people realize how hugely problematic this is.. I've tried to install Firefox on several people's macs (computer novices), but they get so fed up with the documents all over their desktop that they just go back to Safari !

The deleteonexit setting in about:config helps, but it is a very poor work-around.

There's been plenty of talk in the blogosphere about this issue as well:

http://rbtech.blogspot.com/2007/09/firefox-files-****-on-desktop-on-osx.html
http://ask.metafilter.com/24603/Temporary-downloads-in-Firefox-OS-X
http://www.zagz.com/pdf-files-left-by-firefox-on-mac-os-x-desktop/

People have gotten so desperate that they've resorted to Hex editing:

http://forums.mozillazine.org/viewtopic.php?p=3220730#3220730


To repeat: This feature makes firefox unusable for any nearly computer novice.  It irritates almost every Mac user I know, to the point that many of them stick to Safari to avoid the issue.  Is anyone at Mozilla listening -- what will it take to get this issue addressed? 

Comment 21

[Mason]

Just wish to add that this a bug, not a feature, as some have made it out to be.  It is extremely annoying and cannot be worked around via changing a Safari preference ever since Safari 3 came out.

Comment 22

[Per Olofsson]

Is this a dupe of bug 311292? Either way, I posted a workaround that at least doesn't involve hex editing in https://bugzilla.mozilla.org/show_bug.cgi?id=311292#c36

Comment 23

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

Thanks Per for pointing out bug 311292. I wasn't aware of it. And yes, we should mark this one as a dupe of bug 311292. Both handle the same underlying issue.

Comment 24

[db]

As a reporter of this bug I don't agree with that it is a duplicate of #311292. Read the original description again.

Comment 25

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

(In reply to comment #7)
> That is why I linked to the two other bugs.
> 
> Basically, determine the download behaviour (dl, handle internally, handle
> using plugin, dl to tmp dir and open using external app) depending on the mime
> type.

Reading comment 7 which was your detailed explanation:

Firefox determines the download behavior by the way you choose it within the helper application window. Saving a file stores it into the specified download folder. This works fine and the folder can be changed within the preferences.

If you are interested in having a file opened by a helper application, e.g. pdf files, it is downloaded to the temporary folder. This folder is accidentally the desktop or download folder now. Both referenced bugs from your comment 0 states about this issue and make it a dupe of bug 311292.

So please give real arguments why this is not a dupe.

Comment 26

[Tyler B]

I agree that this is a dupe (also, it has a better subject line which doesn't make this important problem sound like a random niche request)

Comment 27

[Till Korten]

I also agree, that it is a duplicate of bug #311292.

If you read that bug report, you will find that there are many duplicates of it around. It would be good for everyone to concentrate our efforts and vote for bug 311292 so that it might get fixed eventually.

Comment 28

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

(In reply to comment #24)
> As a reporter of this bug I don't agree with that it is a duplicate of #311292.
> Read the original description again.

Benjamin, could you please re-check if this is a dupe of bug 311292? Thanks.

Comment 29

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

(In reply to comment #28)
> (In reply to comment #24)
> > As a reporter of this bug I don't agree with that it is a duplicate of #311292.
> > Read the original description again.
> 
> Benjamin, could you please re-check if this is a dupe of bug 311292? Thanks.

Shawn, I'm still sure we should dupe this bug. 

Comment 30

[Marc Bejarano]

(In reply to comment #25)
> So please give real arguments why this is not a dupe.

it seems to me like the reporter is requesting an enhancement to allow as much control over behavior as MacIE, which isn't bug 311292.

Comment 31

[andreas.fischlin]

Indeed, not at all. MacIE allowed to specify many more download actions and modes for the actions such as MIME type specific plug-in use and postprocessing etc. Thus hardly related to bug #311292, which is a tiny subset of this issue, i.e. enhancement as requested under bug #374184.

Comment 32

[Eric]

I agree this is not related to bug #311292, and I'd like to throw in my vote for intelligent file handling behavior based on MIME-type (open vs ask to save).

Comment 33

[andreas.fischlin]

This is IMHO not an issue for voting, but one for understanding the problem. As I have explained many, many times (see bug #311292 comment #109, or bug #311292 comment #153), since a long time ago, that the user interface links these issues, even if the actual codes are very different ones. This is what should be seen, but seems never to be understood, by whoever is programing FF and TB for OS X. This is probably also why there is never any progress on bug #311292. I have suggested and designed a very long time ago a dialog that would handle all these issues, i.e. this bug as well as bug #311292 and any implementation needs to follow from that.

Now, of course, dialogs can be implemented differently, and if at least someone from the Mac programmers would ever make the effort to understand the solution I am talking about since years, one could of course also think of alternative solutions than the one I have designed. Dialogs are of course also a question of style and taste. But one has first to understand the key issues at stake and how they are related, irrelevant of style and taste. I repeat what I am saying since a long time: Unless the difficultiesI to understand the application's behavior every user of FF or TB encounters while downloading a file are appreciated by the programers, I fear there will be no progress (see bug #311292 comment #109). The concepts are not thought through and the implementation is unusable as I have explained in every detail in my comments.

The irony is, that here with this bug a rather complex algorithm is needed, while the essential design behind the download behavior of FF and TB on a Mac remains unaddressed and while the implementation of the solution I am suggesting since years would be very simple and a minimum of effort. What a contrast. And Mac users continue to complain, and nobody listens? The download preferences and download behavior of FF 3.6.2 (latest as of this writing) and TB 3.0.3 (latest as of this writing) are both as bad as ever and all my suggestions for improvements were all ignored. Re bug #311292 still no preference to control the temporary folder preference. What a pity for such otherwise nice programs! What a waste of effort!

I am afraid my conclusion and recommendation for FF and TB on the Mac remains therefore the same, see bug #311292 Comment #153.

Comment 35

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

As described in the summary, I think this bug is WONTFIX. It seems to be advocating for fixing a variety of other issues, better expressed by other bugs, specifically:

 - always provide a default action regardless of MIME type (bug 234243 and others)
 - make it easy to specify the download location for temp files (bug 311292)

The other aspects of the MacIE download manager aren't things I think we're interested in taking. Over to Mossop for final say as module owner.

Comment 36

[Shawn Wilsher :sdwilsh]

(In reply to comment #35)
> As described in the summary, I think this bug is WONTFIX. It seems to be
> advocating for fixing a variety of other issues, better expressed by other
> bugs, specifically:
> 
>  - always provide a default action regardless of MIME type (bug 234243 and
> others)
>  - make it easy to specify the download location for temp files (bug 311292)
Agreed.

> The other aspects of the MacIE download manager aren't things I think we're
> interested in taking. Over to Mossop for final say as module owner.
I'm the submodule owner of the download manager, so I can make this call too.