when saving a file [via Save Link or Save Image], the filename in file picker should not include extension, since the filtering should provide the extension. at least it should on win32 and mac --not sure about what's expected on linux/unix [although the correct filter is chosen on my linux box]. recipe A: 1. go to http://cnn.com/ 2. bring up the context menu over the ad banner near the top-right of the page --it's an image file which lacks an extension, it's just called "aol" 3. select Save Image and look at the resulting file picker. results A: on all platforms, the file picker correctly chose the GIF filter. however, the filename in the picker is "aol.gif" rather than just "aol". here's another illustration of where this might actually confuse the user: recipe B: 1. go to http://mozilla.org/ 2. bring up the context menu for the "At A Glance" link on the left side of the page. 3. select Save Link. the resulting file picker says "At A Glance.html" in the filename field. 4. change the filter choice to "Text File", then save the file. results B: the filename in the picker remains as "At A Glance.html", and it's also saved as "At A Glance.html". expected: shouldn't the file have been saved as "At A Glance.txt"? then again i don't know how much this particular case might be affected by bug 42441...

could this bug and bug 115210 be dependent on bug 31519, perchance?

On linux, we had better save under the _exact_ name in the box, without sneakily appending anything to it. Same thing on the mac. If the user chooses to not have a ".gif" extension on a gif file, then we should allow him to do that on those two platforms. This means that the original name we display on linux should include the extension. On the mac we could leave the extension off, and save the file without the extension (just make sure we set the type field correctly). On windows, it seems to me we should follow the system "show extensions" preference, no?

I think sairuh is right about the interdependencies of the three bugs (this one and the two sairuh mentioned.) The Windows "show extensions" setting won't help to resolve this bug, because there is no icon accompanying the file being downloaded. In Windows explorer, a TXT file gets an icon that a Windows user learns to eventually recognize. In the Mozilla save dialog, there won't be any icon. The full filename should be provided on all platforms. Otherwise the user will be confused. This bug should be marked invalid or wontfix.

I agree with those who say that the full filename should be shown, extension and all... I hate software that sneakily adds extensions without my knowledge or consent, or that treats me like a moron by trying to hide "tech stuff" like file extensions from me.

ADT triage team needs info: Does the correct extension now get added in this case recipe B)? Is there a separate bug on that?

See related bug 120313

tested using 2002.02.25.0x comm bits on linux rh7.2 and win2k --unable to test on mac due to bug 107521. with recipe B: issue #1: when i select "text file" from the file picker, the extension remains as .html. and after i click "save" the page is saved as an html file [mozorg.html]. issue #2: however, if i explicitly change the filename in the picker to have an .txt extension [still have "text file" chosen as the save option], the file is saved as "mozorg.txt", but the file itself contains html source. i'm kind of confused now --shouldn't the html source be stripped out? i re-read bug 42441, where saving as text was implemented, and ran a couple of tests: if i save the page via the File > Save Page top-level menu or accel+S, then select the "text file" option, the page is indeed saved as text. however, this doesn't seem to work when i save via the context menu item "Save Link As" and select the "text file" option... should i file another bug for issue #2 [certainly don't want to morph this one]? or, am i encountering the end result of bug 117269 and/or bug 120313?

No, issue #2 is a separate bug. For "Save Link As" we're completely ignoring the user-selected type in the picker... we should either not offer text/plain as a type there or we should do the right thing for it. Please cc me on the new bug?

filed bug 127912 for the saving as text via "save as link" issue.

ADT triage team is still somewhat confused over what cases are not handled by bug 127912. Sarah, could you please explain in person?

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

nsbeta1+ per Nav triage team

nsbeta1- per Nav triage team

Is this... like, halfway fixed now? I tested in the current nightly on Windows 7. "Hide extensions for known file types" is enabled. * Save Page As on this page shows the file extension. This is appropriate, because I don't have CGI associated with anything. * Save Link As on the bug number link at the top of this page hides the file extension. This is not appropriate, for the same reason as above. * Save Image As properly hides the file extension for known file types. * Save Image As makes a bit of mess of things when images are served without an appropriate file extension. For example, thumbnails on Bing image search show as thumbnail.aspx in the file picker, and get saved as thumbnail.aspx.jpg. Given that extensions for known file types are hidden, Windows Explorer shows the resulting image file as thumbnail.aspx, which is confusing.