Throughout our code base, it seems like whenever we set a default string for a save as filepicker <http://mxr.mozilla.org/mozilla-central/source/widget/public/nsIFilePicker.idl#98>, we set it to the file name _with_ the extension. However, the XP filepicker isn't too happy with this. It expects the file name to not have an extension for the save as filter to behave correctly and append one while saving. We should probably remove the extension before passing it in to the XP filepicker. Windows Vista and 7 are happy either way, which means that we can behave consistently across OSes.

where "OSes" is actually "Windows versions".

The same bug has also been opened on Linux (bug 514493) and OS X (bug 514491).

[FTR: The issue is - in Firefox, right click/save a web page as - change the save as file type to something else - notice how the extension at the end of the file doesn't change.] With this patch, on XP the extension disappears from the "File name" input box, but is automatically appended by the file picker. Windows 7 is unaffected. Now this approach requires that the file name that's given to us include the extension. A different way would be for us to require that users of this API not pass in an extension along with the file name, and for us to append it on Mac/Linux by looking at the filter list/default extension. All users of the API that I've looked at do pass in the extension, and the Mac and Linux filepickers expect the extension to be passed in, so I went with this approach. Jim, Vladimir -- comments?

Please fix this comment though, there's a typo - // The save as filepicker on XP doesn't its default filename to have an // extension (if there's already one specified via lpstrDefExt). The save-as filepicker on XP doesn't appreciate the default filename having an extension, vista and up don't mind either case. If lpstrDefExt is already defined, strip the .ext from the file name. or similar.

Oops, sorry, I'd fixed the comment but attached the old patch by mistake. Your text is better anyway -- thanks.

Comment on attachment 398878 [details] [diff] [review] One possible approach Old patch, sorry! Looks fine, if the issue still exists.

Backed out due to regression, bug 555085: http://hg.mozilla.org/mozilla-central/rev/ea70896d2d2e The XP filepicker seems to get really confused with multiple dots in the filename.

(In reply to Siddharth Agarwal [:sid0] from comment #8) > Backed out due to regression, bug 555085: > http://hg.mozilla.org/mozilla-central/rev/ea70896d2d2e > > The XP filepicker seems to get really confused with multiple dots in the > filename. Siddharth, can you give an example for such confusion? I believe this bug has two aspects (pls correct me if I'm wrong): 1) In file picker dialogue: a) If extension of current user-defined filename is one of known file types AND b) user chooses another known file type from File types dropdown: -> Change extension of suggested file name on-the-fly in the dialogue. E.g.: subject.eml -> choose "HTML Files" from FileType -> subject.html (as suggested file name in file picker) 2) a) If user selects specific file type *other than* "All files" AND b) If, for whatever reason (e.g. our failure to achieve 1, or manual input by user), the file extension of dialogue's file name does *not* match the correct file extension for that specific file type AND c) user clicks SAVE -> dialogue done -> We want to append the correct file extension before saving the file E.g.: User's file name is subject.log User-selected file type is "HTML Files" -> After user clicks SAVE, we should change file name to "subject.log.html" If we can't fix 1) (assuming XP dialogue doesn't allow that, or does it?), I believe we could still fix 2) because we know both user-defined filename and file type as two separate return values from the dialogue, and after we get these two values from the dialogue, we can tweak them before saving in whichever way we want. Or not?