Open Bug 142102 Opened 22 years ago Updated 2 years ago

Mozilla adds extension to filename in Save As dialog even when selecting

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

People

(Reporter: ajbu, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Simple testcase using PHP & content-type message/rfc822 as example
509 bytes, text/plain
Details
testcase download dialog
10.71 KB, image/png
Details 
Mozilla build 2002042608, Windows XP Pro.
There are several bugs on file-extensions, but I didn't find one for this.

When saving a file using the 'Save As' dialog, mozilla adds an extension even
when setting another extension, and setting the 'Save as type' to the 'All 
Files' filter.

Steps to reproduce:
1) Go to ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/
2) Click on 'embed-win32.zip'. In the downloading dialog choose 'Save this 
file to disk'
3) In the Save As dialog change 'Save as type' to 'All Files'
4) Change the filename/ set a new extension for example: 'embed-win32.zp3
5) Press on 'Save'

Expected result: The file is saved as 'embed-win32.zp3'
Actual result: The file is saved as 'embed-win32.zp3.zip'
- Mozilla should not try to add  the extension when there already is an 
extension in the filename.
- Mozilla should not add an extension when the 'All Files' filtertype is 
selected.

Even beter demonstration:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.bz2 tries 
to save to mozilla-source.tar.bz2.exe even when trying to remove .exe
When downloading an iso file like: 
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/iso/i386/enigma-i386-disc1.iso
Mozilla adds '.exe' to the filename so saving as 'enigma-i386-disc1.iso.exe'
To file handling.

Mozilla is not adding the extension.  The Windows filepicker is adding the
extension....  Which completely contradicts the documentation for said
filepicker, iirc.
Assignee: new-network-bugs → law
Component: Networking → File Handling
Depends on: exe-san
QA Contact: benc → sairuh
Confirming, I've seen this happen about a zillion times in the last coupla
months on Win98SE, with various builds.

As Boris has already hinted to, this is almost certainly at least related to
either bug 120327 or bug 129969, and my be a duplicate of one of those.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not a duplicate because this is also about adding the extension back after 
removing it from the 'suggested filename'.
Also note that the suggested patch for bug 120327 states:
 function getDefaultExtension(aFilename, aURI, aContentType)
 {
+  if (aContentType == "text/plain")
+    return "";
+  


so this will most likely not fix this, a more general patch is needed I think.
Yeah, this is not a dup, since 120327 deals with the brokenness of the
_suggested_ filename.  Munging the filename once the user has changed it is a
different kettle of fish and is windows-only (unlike bug 120327, which is XP)...
confirming on Win98 and RC2.

I've seen this bug recently (on RC2) even when I'm not changing the suggested
filename . I was downloading a movie file and the suggested name was Foo.mpg and
it got saved as Foo.mpg.mpeg

It's a regression since the 0.9.9 era.
ajbu@planet.nl, what are the extensions listed in the filter when you see this
happen?
Sorry ,my previous was  misleading

In fact the filename on the server was foo.mpg, and when I clicked on it it 
popped me the windows that asked me what I wanted to do with this file (open it 
or save it to disk).

The title of that particular window was already "Downloading foo.mpg.mpeg", I 
chosed to save it to disk and clicked OK and then in the next window it asked 
me to enter the name of the file and the suggested name was foo.mpg.mpeg

The type was *.mpeg in the second window but the suggested name was already 
foo.mpg.mpeg so changing the type was useless.I have to edit the filename 
manually to get rid of the extra .mpeg extension.

I hope it clears things up.
Yeah, that's our buggy "only get one extension per content-type" code on
Windows... makes sense.
This problem is NOT windows specific. It appears on Linux too. If I download an
executable "xyz.abc" it appends a .exe to it, and I manually have to change
"xyz.abc.exe" back to the correct filename as given my the mime info "xyz.abc". 

It just should take the given name and not append its own stuff.
What you are describing is bug 120327.  _This_ bug is a different,
windows-specific issue.
Filters For the .zip:
*.zip 
All Files

For mozilla-source.tar.bz2:
*.exe
All Files
*** Bug 148456 has been marked as a duplicate of this bug. ***
*** Bug 149170 has been marked as a duplicate of this bug. ***
so rereading this, this is basically bug 147679
*** Bug 153846 has been marked as a duplicate of this bug. ***
Depends on: 147679
Summary: Mozilla adds extension ot filename in Save As dialog even when selecting → Mozilla adds extension to filename in Save As dialog even when selecting
Hi, this problem is present in the build 2002061104 (release 1.1 alpha) running
under windows 2000 too.

confirming:	Mozilla 1.1b+, build ID 2002080208, Win NT 4.0
wfm:		Mozilla 1.0rc3, build ID 2002052306, Win 2000

That is surprising. Why doesn't it work in the newer builds anymore? What has
changed?
Example: If I change the proposed extension for sample.asp from sample.asp.html
to sample.asp, Moz 1.0rc3 saves it as I want.

If Mozilla mangles the extension, it should at least respect the user's
modification.

I must correct myself, sorry for the spam. It has nothing changed between the
two builds (for me). The different behavior results from the different Windows
installations.

From my "empirical study":
The standard extension is ONLY added if the desired extension of the user is NOT
registered in Windows (more exact: there is no entry for this extension in the
Windows registry under HKEY_CLASSES_ROOT). This is independent from the used
filter in the Save As dialog under 'Save as type'.

This applies only to the present case, i.e. if the user overrides the proposed
extension in the Save As dialog.
QA Contact: sairuh → petersen
*** Bug 185371 has been marked as a duplicate of this bug. ***
This bug is more serious as may look. Some pages are using php or asp for
downloads and the result is filename.extension.php... even if All Files
selected. To change file type if known extensions are not shown is pain in ***.
This bug occurs even if extension has an application assigned with it. In win98
result looks confusing: i.e. file.zip but opens with php associated application.
OS: win98, win98SE
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
Site example: www.cietnis.lv any file.
I've written for myself a php-script for downloading a file. I named it
index.php and have two ways to call it:

1. http://path_to_script/?file=file.zip
2. http://path_to_script/index.php?file=file.zip

I set the filename:
header( "Content-Disposition: attachment; filename=\"$file\"");

Linux has no problem - with both ways i get the right filename.

But with any version under Windows i can recognize following... The first way
works and i get the filename "file.zip". But the second one fails. I get the
additional extension ".php" with the result "file.zip.php".

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
to comment 21: Did you a left click or right click "save link target as"? This
seems to be bug 164816.

Can anyone explain me the different behavior that I mentioned in comment 18? In
short: If the user overrides the proposed extension in the Save As dialog then
the standard extension (the last proposed ext.) is ONLY added if the desired
extension of the user is NOT registered in Windows.

I mean, if the USER changes the file extension why should Mozilla (or the file
picker) (re)checks for the OS settings for this file type? This is IMO only
acceptable if the user doesn't specify a file extension.
that's an os behavior and isn't even an accurate description of the way windows
behaves.

if you don't like it then use double quotes around the filename. (if double
quotes don't work then that'd be our bug)
> or the file picker

This is the default operating mode of the Windows filepicker if you ask it to
fix up extensions.... (which needs to happen so people can type "foo" for HTML
files and get them saved as foo.html; apparently lots of Windows users expect
this behavior).

If you know how to make it do what's needed without doing incorrect things,
please fix it (I don't know anything about the Win32 API, so...)
This is still happening in 1.3.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

It is ridiculously unhelpful for a browser to see a filename on a web page
called "boeing.mpg" and then prompt with "boeing.mpg.mpeg" as the filename for
the download. I makes saving files take many times the mouse clicks than it should.

I dare say that the confusion involved for some users from multiple file
extensions (hence the plethora of email worms that have exploited this) is, in
its own right, reason enough to raise the severity of this to at least major.

Even more importantly, this is one of those bugs which is just so irritating
that you will NEVER see wide acceptance of Mozilla while it does this.

seems to be triggered by how the file is served. a comma seperated value file i
download from an online database (i hit a button, the server feeds me the file,
from an .asp web page) gets tagged as an .asp file. if i post the same file to
my own server and re-download it (right click, "save as"), it shows up in the
download dialog box as a .csv file, no modification of file extension.

if this is a windows-specific problem that's fine, i understand that it won't
get as high a priority as if it affected downloads on all platforms - but given
the sheer number of windows platforms, this is a problematic bug.

anyone aware of the bug can solve the problem by fixing the file type. however,
the average user (read: anyone who doesn't even realize that windows uses file
extensions, as the default is not to show them in the first place) is going to
run into a bunch of problems here, and blame it on the browser - 'cause other
browsers don't muck with the file name when downloading it. they aren't going to
care if it works fine on linux, they'll just use a different browser.
Any chance that this bug will be fixed in 1.6?
Why Mozilla thinks it is 'text/html' when I say in script headers that
content-type is 'message'rfc822'?
toomas: your comments have nothing to do with this bug.... which mozilla version
are you using, though?
to cbiesinger@web.de:

... latest and greatest of course!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

And why you think it is not same bug?
If you run this script then Mozilla saves file named 'mymessage.eml.htm' not
'mymessage.eml' as expected!

Try yourself: http://bladerunner.dyn.ee/test.php


>And why you think it is not same bug?

this bug is that even if you select a file in the filepicker and choose "All
files", the extension corresponding to the mime type is added.

your bug is that the wrong mime type is displayed. can you file a new bug for
that (file handling component)?
*** Bug 228276 has been marked as a duplicate of this bug. ***
*** Bug 228359 has been marked as a duplicate of this bug. ***
The general problem is that the default extension for the MIME type is appended
when the file already has a valid alternative extension.  Thus, .zp3 becomes
.zp3.zip, .jpg becomes .jpg.jpeg, .mpg becomes .mpg.mpeg, etc.  If the default
extension is already present, the problem does not occur.  

This is more than merely annoying because many of us still use old PC software
that only recognizes the 8.3 file-naming convention in effect prior to Windows
95.  That software still performs the tasks for which it was obtained, and users
don't have to pay for upgrades.  That is why we still see files with .htm and
other 3-character extensions.  

In the meantime, users of Windows 2000 in a network configuration might not have
the ability to expose file extensions.  That is true at a government facility
where I do some volunteer work each week.  The ability to change the display
options is diabled, with "hide extensions" forced.  Thus, a workaround cannot
involve renaming files to remove the extra extension to restore the original
file-name.  Indeed, users cannot even see that the file-name was changed.  

Can this bug be scheduled for fixing?  
 
>The general problem is that the default extension for the MIME type is appended
>when the file already has a valid alternative extension.

I don't see how that is related to this bug, could you explain?
Assignee: law → file-handling
QA Contact: chrispetersen → ian
Response to question in comment #35:  

I came to this conclusion from the statements in the originator's Description;
in comments #7, #20, and #25; and in the Descriptions of some of the other bugs
marked as duplicates of this one.  I then tested my conclusion by creating a Web
page with two identical images, one with the extension .jpeg and one with the
extension .jpg (the former being merely a copy of the latter with a change of
extension).  Saving the former did not add a new extension; it was merely .jpeg.
 Saving the latter added .jpeg as an extension, giving me .jpg.jpeg.  

The test page is at <http://www.rossde.com/test_exts.html>.  No, I have not yet
tested other extensions.  

If my comment #34 does not describe this bug, which bug does it describe?  
you describe bug 163254 as far as I can tell.
Aha!  Comment #37 is correct.  I withdraw my comment #34 and comment #36.  
According to a comment in n.p.m.general, this is not Windows-specific.  Updating
fields.
OS: Windows XP → All
Hardware: PC → All
what's the message id of that newsgroup post?
Christian, I guess you mean this:

Xref: secnews.netscape.com netscape.public.mozilla.wishlist:36907
No, i mean the Message-Id header.
For what it's worth, I've never experienced this bug on any Mozilla up to 1.6.
It only appears for me with 1.7 alpha and 1.7 beta. (Renaming .jpg/.jpeg to .jpe
!) Also, the "Save as type" field is blank, instead of showing "JPEG Image" or such.

Reverting to 1.6 solves the problem.

(Running Windows 98 SE)
Flags: blocking1.7?
(In reply to comment #43)
> For what it's worth, I've never experienced this bug on any Mozilla up to 1.6.

then you're seeing a different bug, please file a new one, giving exact steps to
reproduce.
not likely to block the release on this.
Flags: blocking1.7? → blocking1.7-
This looks windows only - is this correct?
No longer blocks: 372972
This is probably not the best place to ask for it, but should I really fill a new bug to ask whether 

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/content/contentAreaUtils.js&mark=&rev=1.102#854

could be checked out now that bug 120327 has been fixed by attachment 92444 [details] [diff] [review] ?
(In reply to comment #47)
> This is probably not the best place to ask for it, but should I really fill a
> new bug to ask whether 
> 
> http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/content/contentAreaUtils.js&mark=&rev=1.102#854
> 
> could be checked out now that bug 120327 has been fixed by attachment 92444 [details] [diff] [review] ?
Please file a new bug.

For what it is worth.  IE7 (7.0.5730.13) behaves in the "expected" manner by the filer of this bug.  When you override the extension (mime type I'm presuming) it preserves that.  I.e., whatever I type for the filename is exactly what is saved. 

In my case, I'm trying to download Access database files.  They are saved as 2003 and I have the 2007 version installed.  When saving, my machine wants to save them as .accdb because that is the registered file extension for Access on my machine, but it really needs to be .mdb because it is a v2003 file.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Product: Core → Firefox
Version: Trunk → unspecified
Why is this bug now limited to Firefox?  Why is it not a Core issue that also impacts SeaMonkey?

I had a similar issue with Firefox 100-102. Everytime I downloaded an .exe file it got saved with an additional ".sig" file extension.

The reson for this was (after I searched for sig and "sig" in the profile folder) was that "sig" was somehow registered in "handlers.json" as the extension for the mime-type "application/ms-dos-application". After removing this entry manually from the json file everything is now fine again.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates and 19 votes.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: