If you've already set all of your prefs to automatically save or "open with" just about every downloadable MIME type, you may want to create a new profile to test this bug. Find a file on the web with a MIME type for which you have not set this pref and click to download the file. If you choose "save to disk", Mozilla will then prompt you for a file name and a directory in which to save. The default filename is very reasonable. However, if you choose "open with application", then Mozilla will save the file to disk with a garbarge filename (maybe something from the cache system?) and have the application open that file. The result is that your download directory can get cluttered with garbage-named files. I like the fact that the files are there, but I wish that they had resonable names. If mozilla can suggest a reasonable default "save-as" filename, then it seems buggy to *not* do that when saving for purposes of "open with application". I think the ideal behavior would be to start the download and check the content disposition headers for suggested names. If none are found, then use everything after the final '/' in the URL (or after the penultimate '/' if the '/' is the final character). This is (I think) consistent with Navigator 4.x. At least I know NN honors "stuff after the slash", but I'm not sure about the content-disposition headers. A nit-pick... Some cgi scripts support things like http://example.com/path/to/script.cgi?foo=bar;baz=bip;save_as=/filename.ext which allows the link to be saved, and in a hackish sort of manner suggests that the file should be saved as filename.ext. The save_as parameter is totally ignored by the script, but it may generate HTML with those sorts of links so that users can have a decent file name (in this example "filename.ext") for the output it will send when they call the script with those parameters. Supporting this costs little, and is Good Thing as it is consistant with NN 4.x and it will prevent things from breaking that used to work with 4.x Not supporting this is a Bad Thing. MSIE doesn't support this. MSIE will take a link like the above, and suggest that you save the resulting file as script.cgi. Now suppose that script had generated a few dozen links, each with a suggested filename appropriate to the content you would receive based on the unique parameter values in the URL. NN 4.x would save each file with the suggested filename. MSIE would want to save them all as script.cgi. NN good. MSIE bad. -matt

You can suggest a filename with the Content-Disposition header: Content-Disposition: attachment; filename="foo.bar" What you're seeing here, however is a security feature. If the user is saving a file, the user puts the file somewhere on the hard drive. If mozilla is saving a file to open with a helper it will be saving it to a temporary directory. That is, to a known location on the hard drive (hardly anyone ever has a temp dir with a non-default name). If we kept the suggested filename from the server, this would allow the server to place content of its choosing in a know location on the hard drive under a known name. This is the classic first step to launching _any_ security exploit. This bug is a duplicate, but I cannot find the original.

well, perhaps I'm after a feature request then... if Mozilla were to prompt me for a filename during "open with application" [OWA hereafter] then that would be just as [in]secure as "save file to disk" [SFTD hereafter]. Generally, when a user does SFTD, they're sooner or later going to open that file in some application. They are almost never going to first poke at it with a hex editor to be sure it's clean. So, if we can accept that level of security with SFTD, then why can't we accpet that level of security with OWA? I would like to at least have the option of specifying the name. Perhaps the dialog which asks what you want to do with the file (SFTD or OWA) can be expanded to include the filename, the default save directory, and a "browse" button to select a different directory. This would eliminate the second dialog in the SFTD case, and it would allow the user to eliminate the garbage name in the OWA case. This security feature is massively annoying when I'm downloading my own gzip files and I *know* I trust them, and want to gunzip them. I either have to do it in two steps (SFTD, then gunzip) or I have to have a bunch of random-named gzip files laying around... which if I wanted to move to another local machine, I'd have to inspect and rename appropriately, or (more often) waste effort re-gziping from the decompressed content because it's a bit easier. This security feature is something I'd like to see be a bit less anoying, either through additional options in the interface or through some new prefs. I was actually suprised to find this unreported. I beleive you that it's a dup, but I wasn't able to find it either, searching for name, filename, file, save and other likely terms. I figured I'd find a dozen bugs. Is nobody else annoyed by this feature? -matt

The file name handed off to helper apps should now be "correct;" this was fixed for bug 60203. *** This bug has been marked as a duplicate of 60203 ***

vrfy dup