Closed Bug 57113 Opened 20 years ago Closed 19 years ago

Filename 3-letter extension not applied when filename altered

Categories

(Core Graveyard :: File Handling, defect, P3)

x86
Windows 2000

Tracking

(Not tracked)

VERIFIED FIXED
Future

People

(Reporter: Spyder1344, Assigned: law)

References

()

Details

(Keywords: helpwanted)

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 locka@iol.ie 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
QA Contact: benc → sairuh
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
Summary: When filename 3-letter extension not applied when fileanme altered → When filename 3-letter extension not applied when filename altered
Blocks: 55025
*** 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
Keywords: nsbeta1
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.
Keywords: helpwanted
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.
Blocks: 101254
Patch in bug 117269 fixes this.
Depends on: 117269
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
Depends on: 414865
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.