Save dialog gives you all the choice to view filetypes it *believes* you want to see. For example. I download a XUL file, which the webserver reported as plain/text. The save dialog refused to give me the choice of *.xul in the directory, but instead only gave *.txt and *.text in the "files of type" dropdown menu. This I believe is incorrect. The user should be given the choice of "most popular filters" including a "all types *.*" filter. Downloading a .gz file does not mean one only want's to see *.gz files in the directory. In addition to always providing a "all types *.*" type, I believe the dropdown list should be a edit/dropdown list, just as the location bar. Giving the user to enter the filter of their choice. eg. "*.xul" for a plain/text file.

Another thing... Mozilla should add a filter with the extension of the downoaded file in the dropdown list if it is not already in a suggested filter, as a convenience to the user. For example if the file being download is a .txt file with plain/text mimetype, then the user sees the "Text (*.txt *.text)" filter only, as the file's extension is already available in an existing filter. But if the user is downloading a .bat file with a plain/text mimetype, then the user sees not only the "Text (*.txt *.text)" filter but also a "BAT ( *.bat )" filter which was derived from the filename. This convience filter feature could be limited to only file extensions under "x" number of characters for security reasons if need be.

To file handling. This is Ben's bug.

All that's needed is the removal of the "else" at http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/conten tAreaUtils.js#322 to make the appending of the *.* filter unconditional...

Also, is there a good reason not to use the predefined nsIFilePicker::filterAll for the *.* filter?

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

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

This is XP.

Not sure if this belongs here or not, but there does appear to be a UI issue with this bug and ones like bug 120327 and bug 126260. Under NN4.75 (Linux at least) the text next to the drop down list in the save dialog is "Format for Saved Document", while under Mozilla it's "Files of type". I think one issue complicating these bugs is that this drop down is actually being used for three things: 1) It acts as a filter for the file listing. 2) It acts as a save format selector. 3) It acts as a extension selector for the saved file. As an example if you are saving a page under NN4.75 and change the option from "text" to "source" it: 1) Changes the filter and 2) Changes the save format and 3) Changes the extension. Under Mozilla it only: 1) Changes the filter and 2) Changes the save format. Is part of the issue that the same filepicker is being used for both "Open" and "Save" operations? The "Files of type" label makes sense for "Open" but not so much for "Save" where I think NN's label makes more sense. Does there need to be two(!) drop downs? One would show the file format and one would show the filter. It would be a little better to at least change the label for the drop down in the file menu to "Format for Saved Document" but this will cause confusion when/if an option like "All files (*.*)" is added.

follower I think you got some good points here: LINUX doesnt really connect the file name (and hence the extension) to types of files, even if it is frequently done by convenience and convention. That means I could want to save an HTML file as x.txt and the version of that file that has been converted to text as y.html if I wish and mozilla shouldnt prevent that. If I choose to do so, I might use only files without extension for all kinds of different file types. Clearly the file type selector should also not be confused with a name filter. The filpicker UI redesign bug 125133 proposes a design in attachment #75569 [details] that has a seperate field for filtering file names. (and file type dropdown text shoul not show extensions). This gets a bit complicated through the fact that the same filepicker is used for opening and saveing files: for opening the file type selector would need to use more sophisticated ways of determining the type (e.g. magic number) or dropped completely if there is a filter field.

OK. The save filepicker now always lists the *.* filter. Are we keeping this open for something else from comment 0? If so, for which?

As I said in comment #9 this feature is a mess: whether a file gets stored together with image files (web page complete) has nothing to do with the type. And the type has nothing to do with a directory listing filter. I would recommend to leave this open until there is a good proposal how to untangle these different functions and more specific bugs have been filed.

A side effect is you get completely broken behaviour on broken servers like TwitPic where the drop down box is completely empty. See: http://img35.imageshack.us/img35/8800/enternameoffiletosaveto.png A workaround (on windows at least) is to type * in the name box and pressing enter). Although luckily, this is not required in the pathological case above.

(In reply to comment #12) > where the drop down box is completely empty. This is a separate bug. On Windows, this behavior may be caused by bug 484579, that was fixed Firefox 3.5. If you're using the latest version and you still have the save problem, please file a separate bug report and we'll investigate.