Have a look at my screenshot. I created it by downloading one of the foo files from this test page: http://entropymine.com/jason/testbed/mime/ So what I would like to do now is save the file to disk... actually, I have little choice, have I? The problem is, I want to stop Firefox bothering me each time I download such a file. IOW, I want to set the checkbox "do this automatically for files like this from now on" Why is that grayed out? For almost every second download I do, it's grayed out. This should never be grayed out, it should always be selectable.

It's always grayed out for files of type "application/octet-stream" and this is intentional, see bug 201546 and bug 126061. *** This bug has been marked as a duplicate of 201546 ***

bug 201546 has been closed to avoid that a user once says for a generic binary file "Open with ..." something and then all these generic binaries are opened with it. But I don't want to open them with anything. And bug 126061 is about always showing the dialog, but I want to never show it. Is there no way to say that all downloads I start should always be saved to disk? It's extremely bothering to always confirm this stupid dialog.

Maybe you missed my point. If there is only one action I can do (and I don't complain about that in this bug!), why do I have to confirm over and over again that I want to do the only action I can do, instead of once saying "If that is the only action I can do, do it without bothering me first". From the book of good software design principles: "If there is something your application can do without user interaction, do it without user interaction, unless you have a really good reason for bothering the user for nothing." So, what is the good reason here? What harm could it do if files of unknown data format are always saved to disk? A saved file is never of any harm. The only harm arrises from starting the file. As long as it lives peacefully in some temp folder on my HD, the only harm is that it might be using space.

> bug 126061 is about always showing the dialog, but I want to never show it. In fact, bug 126061 requests that the save dialog be shown instead of the download dialog, which is exactly what you are asking for. The save dialog can already be turned off by selecting a default download folder in the prefs. But the reason given there for rejecting that proposal may be no longer valid now, since selecting a helper app is no longer possible... So I'd say that though this is a dup of one of the older bugs, you still have a valid point here, because the behaviour of the dialog is now somewhat different from what it used to be. Regarding the dialog itself: It conveys at least two useful bits of information, the file name and the server from which the file is downloaded. Read bug 275417 and bug 276517 for why this might be important to the user. Reopening for the UI issue and over to File Handling for further consideration.

> Reopening for the UI issue those don't belong to core

With Steve Gillmor *and* slashdot posters complaining, this is obviously priority omega, purple alert! ;-) Seriously, it's bugging people. Should be easy to fix. To whom should this bug be assigned? /be

Yeah, this is pretty annoying, I'll take it.

*** Bug 240230 has been marked as a duplicate of this bug. ***

We do still allow people to turn off the filepicker, don't we? So when I do that, and then, ahem, browse image galleries that sometimes seem to think I need a dialer program, are they going to be able to drop "ThatCoolGameYouWanted.exe" in my downloaded files directory for me to find days later without me needing or getting to do anything about it at the time?

I don't think that's within the scope of this bug, exactly. That's more of an "unrequested download handling" issue that may need to be addressed at some point.

The handling of content-disposition is all about "unrequested download handling", it seems to me...

Maybe I'm confused. I thought this bug was about downloads of application/octet-stream, which currently bring up the "Opening filename.exe" dialog, with "Do this automatically" greyed out and "open with" disabled if the filename extension smells executable. If you let me choose to always save, then when I hit an application/octet-stream file named "tasty.cheese" I will choose to always save, not knowing that it also will apply to executables and thousands of other sorts of octet-streams, and because I save all files in the same place automatically, when I then hit a page with a 1x1 iframe with src="dialer.exe" it will save it automatically, and if I don't notice whichever parts of the download manager I might choose to show popping up while it downloads, I'll wonder what I downloaded days later, and find out by running it. Avoiding that is the whole reason we are currently annoying in this situation, so I don't see how it could be out of scope for a bug that wants to remove that annoyance.

Ok, I'll clarify... There are two problems here: Problem 1: If my prefs are to always save files to folder X, and I hit a content type that I cannot Open With, why am I being prompted each time? Given that we content-sniff and handle binary-sent-as-text/plain as application/octet-stream, this is just going to annoy users, because we're going to hammer them with dialogs on misconfigured servers. This excludes unrequested downloads (using the popup-blocking metric of requested) because those can bypass this via other methods. Problem 2: If my prefs are set to always save files to folder X, unrequested downloads may end up in my downloads folder, leaving me vulnerable if I'm not aggressive about checking stuff that's lying around there, and I'm not running antispyware/virus checkers that pick up on these as the download happens. Still, its a problem that needs to be solved. One option is to block unrequested downloads and use the infobar to show that the download was blocked, and allow users to whitelist the site for automagic downloading and/or download the file.

I had seen this bug go away in some of the prior releases of Firefox, but it seems to be back now. Starting in 1.5, if I try to download a file of type wmv, Firefox asks me what I want to do with the file, and ignores my preference to open it in Windows Media Player. Other file types are handled properly.

Michael: What you are seeing is likely related to bug 236541, not this one (unless the wmv is incorrectly served with content type "application/octet-stream"). This issue has never been fixed before.

Thanks! I've submitted it at the bug that you referred me to. Michael

(In reply to comment #14) > If my prefs are set to always save files to folder X, unrequested downloads may > end up in my downloads folder, leaving me vulnerable if I'm not aggressive > about checking stuff that's lying around there, and I'm not running > antispyware/virus checkers that pick up on these as the download happens. Unusual circumstance or not, right now that's "will end up in my downloads folder, leaving me vulnerable full stop." We never would have considered keeping people from automatically saving WMF images, and you don't need to ever open them, just have them indexed by Google Desktop, to get the virus du jour. I'm not sure whether that means we should give up, since any content might be tomorrow's vector, or we should be even more annoying than we are already; we are, however, getting partial praise in WMF expoit reports because unlike IE we "provide a warning dialog before opening the file."

(In reply to comment #12) > The handling of content-disposition is all about "unrequested download > handling", it seems to me... But that's bug 236541. Right? /be

*** Bug 321744 has been marked as a duplicate of this bug. ***

> But that's bug 236541. Right? The Gecko end is. Firefox's handling of what Gecko tells it is not.

(In reply to comment #14) > Still, its a problem that needs to be solved. One option is to block > unrequested downloads and use the infobar to show that the download was > blocked, and allow users to whitelist the site for automagic downloading and/or > download the file. I don't know if distinguishing requested from unrequested downloads is feasible. LOTS of websites offer downloads via pages that redirect to the file through whatever method, with a message on the page like "Click here if the download does not start automatically." While that does provide a workaround, it would make Firefox seem broken by not being able to "automatically" download. Whitelisting seems overkill too because odds are I just need whatever I'm currently getting from that site and won't be returning any time soon.

(In reply to comment #14) > I cannot Open With, why am I being prompted each time? Given that we To verify that you want to download the file which has no associated content handler. I think that makes sense, really. The current dialog -- with all its greyed out goo -- is a little heavy in this case, and maybe we can lighten it for this special case. Just ask them if yes, indeed, they do want to download this file. > Still, its a problem that needs to be solved. One option is to block > unrequested downloads and use the infobar to show that the download was > blocked, and allow users to whitelist the site for automagic downloading Hm, I threw up in my mouth a little, but I see where you're coming from. I think comment 22 is more right than wrong, though, saying that this is already such a common case on the web that requiring explicit whitelisting would be bad, bad times. Also, not really in the scope of this bug, so happily, we can stop talking about it. ;)

Right now, we're talking about a modal dialog, which frankly fails to play well with tabs. Whitelisting would bypass the prompt/infobar completely, but would not be required, or require extra clicks. (Throwaway thought here, assuming we allow more than one button in browsermessage) [www.mozilla.org has offered foo.exe for download [Download File] [Options \/] ]

How would that play with POST data?

Ideally, in the same way the modal dialog does currently (iirc, its dependent, not modal, so I don't think its impossible, I haven't looked at the underlying code yet). Hitting Download would have the same effect as clicking OK on the current dialog.

(In reply to comment #24) > (Throwaway thought here, assuming we allow more than one button in > browsermessage) > > [www.mozilla.org has offered foo.exe for download [Download File] [Options \/] > ] If this is your throwaway thought, I need to wade through your trash more often. Might I suggest that instead of "offered", we go with ..: { Download %S from %S? [ Download ] [ Cancel ] } I still think white/blacklisting is adding a bunch of unneccessary overhead here, though.

The current dialog just downloads the file to a .part filename (in /tmp? Not sure anymore) until you click OK, then renames it...

More kill dialogs with browsermessage stuff, depends on browsermessage changes in bug 268590

You could just add the "useless-UI" key word, and remove the checkbox completely.

Summarizing - is this what was decided upon? If download preferences are set to always save files to folder X, use the infobar to verify the downloading of files without an associated content handler: { Download %S from %S? [ Download ] [ Cancel ] }

I think that this is the right solution for problem #2 as described by mconnor in comment 14, which is to say, it's the right way to handle downloads that aren't directly initiated by user action but which the pref settings would otherwise just save to disk. I'm not sure it's the right solution to problem #1, though, which is that sometimes we can't offer an open-with and have decided that it would be improper to offer a "always save", so really, that dialog becomes quite useless. For that problem, I actually prefer the solution I posited in comment 23, which is to change the download dialog to explain what exactly is going on: You have chosen to open [ ] file.foo which is an Unknown type of file from http://somewhere.somewhere.com Would you like to save this file? [ Yes ] [ No ]

This patch implements Beltzner's suggestion in comment #32, fixing Problem #1. It simplifies the UI by removing the unavailable choices, and presents a simple yes/no for the only available choice.

Comment on attachment 225913 [details] [diff] [review] implements beltzners suggestion for problem #1 >+unknownAccept.label=Yes >+unknownCancel.label=No in pursuit of better button labelling, Save File/Cancel is what we want here. >+ <hbox align="center" id="basicBox" style="display: none;"> >+ <label value="&unknownPromptText.label;" id="from"/> >+ <description id="source" class="plain" crop="start" flex="1"/> >+ </hbox> use collapsed="true" instead of re-resolving style >- this.initAppAndSaveToDiskValues(); >+ // hide featured choice >+ this.mDialog.document.getElementById("normalBox").style.display = "none"; >+ // show basic choice >+ this.mDialog.document.getElementById("basicBox").style.display = "block"; collapsed instead of style (faster/cleaner) >+ // change button labels >+ this.mDialog.document.documentElement.getButton("accept").label = this.dialogElement("strings").getString("unknownAccept.label"); >+ this.mDialog.document.documentElement.getButton("cancel").label = this.dialogElement("strings").getString("unknownCancel.label"); >+ // hide other handler >+ this.mDialog.document.getElementById("openHandler").style.display = "none"; collapsed here too. r=me with those addressed

pushing out non-critical-path bugs to b2

(In reply to comment #32) > I think that this is the right solution for problem #2 as described by mconnor > in comment 14, which is to say, it's the right way to handle downloads that > aren't directly initiated by user action but which the pref settings would > otherwise just save to disk. > As this issue is quite distinct from the original intent of this bug, I moved it to bug 344267.

Comment on attachment 225913 [details] [diff] [review] implements beltzners suggestion for problem #1 a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and mark fixed1.8.1 after you have done so.

(In reply to comment #34) > (From update of attachment 225913 [details] [diff] [review] [edit]) > > >+unknownAccept.label=Yes > >+unknownCancel.label=No > > in pursuit of better button labelling, Save File/Cancel is what we want here. Save File/Cancel was also what was checked in on trunk, but the branch checkin still have Yes/No. Mistake?

(In reply to comment #39) > (In reply to comment #34) > > (From update of attachment 225913 [details] [diff] [review] [edit] [edit]) > > > > >+unknownAccept.label=Yes > > >+unknownCancel.label=No > > > > in pursuit of better button labelling, Save File/Cancel is what we want here. > > Save File/Cancel was also what was checked in on trunk, but the branch checkin > still have Yes/No. Mistake? > Yes, mistake. I'll update it when the tree re-opens.

(In reply to comment #40) > (In reply to comment #39) > > (In reply to comment #34) > > > (From update of attachment 225913 [details] [diff] [review] [edit] [edit] [edit]) > > > > > > >+unknownAccept.label=Yes > > > >+unknownCancel.label=No > > > > > > in pursuit of better button labelling, Save File/Cancel is what we want here. > > > > Save File/Cancel was also what was checked in on trunk, but the branch checkin > > still have Yes/No. Mistake? > > > > Yes, mistake. I'll update it when the tree re-opens. > Fixed on branch

(In reply to comment #41) > Fixed on branch As you changed the wording but left the old property names, some locales may not notice this change and not update it (i.e. still use direct translations of "Yes" and "No" insted of "Save File" and "Cancel"). Please at least announce it in mozilla.dev.l10n.

(In reply to comment #42) > (In reply to comment #41) > > Fixed on branch > > As you changed the wording but left the old property names, some locales may > not notice this change and not update it (i.e. still use direct translations of > "Yes" and "No" insted of "Save File" and "Cancel"). > > Please at least announce it in mozilla.dev.l10n. > Thanks, I posted there to notify localizers of the changes.

Any chance to get the normal (full) download dialog back, maybe with a new pref? what if i want to set "always save on disk" as default action for the "unknown content-type" application/x-msdos-program (application)? Please do not patronize users with this "you are not allowed to set a default action for this" thing, while it is not possible to add a default action using the preferences dialog.

If I'm seeing this dialog for the majority of my downloads, regardless of what's configured in my options. Does this mean something's configured incorrectly on my company's proxy server?

(In reply to comment #45) > If I'm seeing this dialog for the majority of my downloads, regardless of > what's configured in my options. Does this mean something's configured > incorrectly on my company's proxy server? Oh wow, this is annoying. I can't even open a WAV file now. I'd much prefer the old dialog, with the option disabled than having to save everything before opening it. Filed bug 347230. This is definitely not an improvement for me. Hopefully we can find some middle ground.

(In reply to comment #44) > Please do not patronize users with this "you are not allowed to set a default > action for this" thing, while it is not possible to add a default action using > the preferences dialog. The problem here is expressed as "problem 2" in comment 14 in this bug. I've filed bug 347289 to handle that case. I'm not sure that an "Always do this" makes sense here, since we show this for unknown content types, which could be a lot of types of files, or misconfigured servers. Please do file a separate bug on that (blocking on bug 347289) though, as I think it's worth discussing.

(In reply to comment #47 [Mike Beltzner]) > (In reply to comment #44) > > Please do not patronize users with this "you are not allowed to set a > > default action for this" thing, while it is not possible to add a default > > action using the preferences dialog. > > The problem here is expressed as "problem 2" in comment 14 in this bug. I don't think that's the case. Comment 44 appears to believe that the new "Save" dialog is appearing for cases such as a previously-unrecognized application/x-msdos-program. This capability is *still* there. The "Save" dialog is only shown if the file has MIME type of "application/octet-stream". I think the problem is, comment 44 hasn't understood the difference between "file extension" and "MIME type." This whole business of hiding the MIME type info so as not to confuse novice users runs smack into this problem: the *only* way to understand what's going on here is to understand the difference between "application/octet-stream" and a regular MIME type, and why the former is considered a security issue for which "save" is the only reasonable option. This "Save" dialog should have better text on it than "You have chosen to download BLAH.BLA *which is a BLA-Manager file*" (emphasis mine). By stating that this file is a particular type, the user's reasonable question is, "Then why don't you handle it like one?" Until Mozilla can do a better job of answering that question (and as long as Outlook Express uses this MIME type for practically everything) user frustration will continue.

It really needs to be somehow possible to perform a certain action by default no matter what the mimetype file downloaded is. Whitelists are too heavy, but how about second option for the dangerous types "do this automatically for files like this today from this site"

Obviously this is back in 2.0.0.6.

Bug still exists for RAR files in 2.0.0.11!!

could the download manager actually be fixed to work? it doesnt function correctly, the bug listed here is only part of the problems and inconsistencies the download manager faces. this bug is annoying and needs to be addressed. i should be able to go in to the download options menu and find a setting to search for an extension (not mime type) and tell it what i want to do with it (save always, open (with) always, always ask, etc.) and if that extension isnt in the menu i should have the ability to ADD IT.