Open Bug 142102 Opened 23 years ago Updated 3 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: