Closed Bug 57113 Opened 20 years ago Closed 19 years ago
Filename 3-letter extension not applied when filename altered
Using Mozilla M18 Win32 Build ID: 2000091312 When you click on a file to download (i.e. the latest nightly build on Mozilla) and you add a character or a string to the end of the filename, it does not append the 3-letter extension to the file. Steps to recreate: 1. go to www.mozilla.org (like that's not your homepage anyway). 2. click on the latest nightly build for Win32. 3. when you are prompted to Open with the default app or save to disk, choose save to disk. 4. when the "save as" window pops up, you should be able to alter the default filename (default:"mozilla-win32-talkback"), add any character or string to the end of the default filename. 5.download. 6. note that the file is not saved as a .zip file(it has no extension), even though the "save as" box has "*.zip" as the file type.
NOTE: This requires the the Windows switch for "Hide file extensions for known file types" be turned on. Confirmed with 2000101720 on Win2k both that .zip is added if nothing is changed and that it's not added if you do change the filename. Changing companant to Networking as that's what other download related bugs seem to be.
Status: UNCONFIRMED → NEW
Component: ActiveX Wrapper → Networking
Ever confirmed: true
Also, reassigning bug from email@example.com to owner of Browser:Networking
Assignee: locka → gagan
QA Contact: cpratt → tever
nope! not networking. This is law.
Assignee: gagan → law
mass move, v2. qa to me.
QA Contact: tever → benc
Bill: should the component (& qa contact) be changed?
Changing component and setting target milestone. Will likely require changes to the Win32 implementation of nsIFilePicker.
Component: Networking → XP Apps: GUI Features
Target Milestone: --- → mozilla0.9.7
Isn't this a sorta-dupe of Bugs 101254 and 55025?
Mass moving bugs that won't get fixed this milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 101254 has been marked as a duplicate of this bug. ***
As this is fixed, please keep bug 117269 and keep this fix windows-only. There should be no extension-forcing on Mac or Unix, where type detection for files is not tied to extensions.
I meant "keep in mind bug 117269"
*** Bug 118329 has been marked as a duplicate of this bug. ***
Component: XP Apps: GUI Features → File Handling
Summary: When filename 3-letter extension not applied when filename altered → Filename 3-letter extension not applied when filename altered
*** Bug 92158 has been marked as a duplicate of this bug. ***
Pushing out. I think to fix this we need to add a "defaultExtension" attribute to nsIFilePicker. Then on Windows, we take that and put it in ofn.lpstrDefExt. The tricky part is finding all the file picker callers and getting them to set this attribute. There are a fair number of places impacted and I don't know how hard it would be to find them all. If somebody else wants to have a go at it, feel free. I have to remove it from my mozilla0.9.9 plate.
Target Milestone: mozilla0.9.9 → Future
How can this be futured when bug 101254 (which was marked dupe of this one) was nsbeta1+'ed?
How can we fix every single bug? I will gladly reassign to somebody who has the time to spend on this. I don't have the time. Sorry.
This got fixed by the checkin for 117269
er, even resolving. :)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
0.9.9 branch build 2002-03-09-13, Win2k: * Go to http://home.snafu.de/tilman/mozilla/mozilla-uber-alles.jpg * Right-click the image * Choose "Save Image" * Type "abc" in the "File name" field and press Enter Expected results: File is saved as "abc.jpg". Actual results: File is saved as "abc.jpeg". Should I reopen this bug or file a new?
That is in fact the design behavior... .jpeg and .jpg are both valid JPEG extensions and .jpeg is the more correct one. In the same way, we save HTML files as .html instead of .htm Does this mess things up on Windows?
It doesn't mess things up, but this behavior is against the platform standard. If the file name field is changed from something with an extension to something without an extension, the exact same extension should be applied. Even if .jpeg is more correct than .jpg, it should apply ".jpg" if that is the extension of the original file. So, should I reopen this bug or file a new one?
Ah. I misunderstood what you were saying, initially. I don't have a windows build, but I put in some dump() calls to see what we set as the default extension for the filepicker for that image and it's "jpg". If you're seeing the issue you describe in comment 20 and comment 21 on the trunk, please open a new bug on that.
Bug 129979 created.
vrfy'ing since bug 117269 has been fixed --and since bug 129979 covers the remaining issue.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.