57113 - Filename 3-letter extension not applied when filename altered

Status: VERIFIED FIXED

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

Description

[Lee Sam]

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.

Comment 1

[Jacob Steenhagen]

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.

Comment 2

[Jacob Steenhagen]

Also, reassigning bug from [e-mail] to owner of Browser:Networking

Comment 3

[Gagan]

nope! not networking. This is law. 

Comment 4

[benc]

mass move, v2.
qa to me.

Comment 5

[benc]

Bill: should the component (& qa contact) be changed?

Comment 6

[Bill Law]

Changing component and setting target milestone.  Will likely require changes 
to the Win32 implementation of nsIFilePicker.

Comment 7

[Gabriel Seah]

Isn't this a sorta-dupe of Bugs 101254 and 55025?

Comment 8

[Bill Law]

Mass moving bugs that won't get fixed this milestone.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

I meant "keep in mind bug 117269"

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Bill Law]

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.

Comment 15

[Jonas Jørgensen]

How can this be futured when bug 101254 (which was marked dupe of this one) was
nsbeta1+'ed?

Comment 16

[Bill Law]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Patch in bug 117269 fixes this.

Comment 18

[Boris Zbarsky [:bzbarsky]]

This got fixed by the checkin for 117269

Comment 19

[Boris Zbarsky [:bzbarsky]]

er, even resolving.  :)

Comment 20

[Jonas Jørgensen]

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?

Comment 21

[Boris Zbarsky [:bzbarsky]]

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?

Comment 22

[Jonas Jørgensen]

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?

Comment 23

[Boris Zbarsky [:bzbarsky]]

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.

Comment 24

[Skewer]

Bug 129979 created.

Comment 25

[sairuh (rarely reading bugmail)]

vrfy'ing since bug 117269 has been fixed --and since bug 129979 covers the
remaining issue.