Closed Bug 188058 Opened 22 years ago Closed 21 years ago

When saving a .zip file "as...," Moz appends a .x after the .zip extension.


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

Windows XP


(Not tracked)



(Reporter: samdu, Assigned: Biesinger)



(Keywords: fixed1.4.1)


(7 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

Like a fixed bug in a previous build of 1.2 (or 1.1), when you right click on a
zip file and choose "Save Link Target As...," Mozilla appends a .x to the
extension in the save dialogue box.

Reproducible: Always

Steps to Reproduce:
1. Locate a downloadable zip file.
2. Right click.
3. Choose Save Link Target As...
4. Notice the appended .x extension.

Actual Results:  
.x appended to file name. Note: If one manually removes the .x, the file name
saves correctly. As I recall, the previous manifestation of this bug applied the
.x regardless.

Expected Results:  
Left the file name as is.
-> File Handling
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → petersen
Whiteboard: DUPEME
same here 2003011713 trunk win2k, very annoying
Ever confirmed: true, is ".x" mapped as an extension for zip files on your
Windows install?
no and neither does mozilla know a helper applicaton for .x
So could you list some detailed (step by step) instructions to reproduce?  I am
at a loss as to where the ".x" would be coming from....
just trying to download a .zip file eg.
if i just left click, mozilla converts it to .zip.x and filetype *.x
if a shift+left click is converts to .zip.x and filetype is empty
Hmm.. any chance you could run regmon
( while you do that?  I'd
love to see the registry access log...
Attached file Regmon Log
btw, the download of regmon worked as expected, no .x
So... according to that log, we looked "application/zip", found no info, looked
up the helper for the ".zip" extension, found WinZip.

So we should be ending up with an extension of ".zip" as the extension for the
data.... and I still have no idea where the .x is coming from.

Michael, do you build, by any chance?
nope, too dumb and too poor for it
ok..  taking this while I investigate...

Michael, you say it's a problem for the server in comment 6 (for
that particular url) but not for other servers (eg the regmon one)?  Is it a
problem for places other than

If not, could you get an http log?  The way to do this is to, from a prompt, run:

set NSPR_LOG_FILE=c:\log.txt

and then just load the one url that causes trouble in Mozilla, check that the
filepicker is showing the wrong filename, and quit.  Then attach that log to
this bug...
Whiteboard: DUPEME
Assignee: law → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.4alpha
Attached file HTTP Log
its happening on other servers as well, will keep an eye out tomorrow so i may
give a list of urls, beside that, heres the http log
Michael, could you clear your cache then get the log?  That log doesn't show the
server headers because the data just came from cache...
Attachment #112044 - Attachment mime type: application/octet-stream → application/x-zip-compressed
So.. the first two send the file as application/x-zip-compressed and are
Microsoft IIS servers.

The others send it as application/zip and are Apache servers....

Could you do me a favor?  Try the following two links:

(these won't work once my IP changes, but should be ok for the next few
hours...).  What happens with those two?
first fails, 
second ok
OK.  So it looks like the problem is only with application/zip content...  You
have nothing in your preference dialog for this type, correct?

For some reason we're coming out with application/zip mapped to the ".x"
extension; just not sure why....
hrrrm, now there is, but im sure there wasnt when i looked last time
since then i downgraded to 1.0.2 cause trunk nightlies didnt like me lately,
how about you sam ?
yay, its back.
i delted it last time, then everything was ok, now its again adding the .x
BUT ... once again, .x AINT in my helpers list
Hmm.  Could you possibly send me your mimeTypes.rdf file?  Or attach it to this
bug?  (As I said, I'm seriously at a loss as to where that .x is coming from....)
Attached file mimeTypes.rdf
Alright.  No .x there....

pkw?  biesi?  timeless?  does one of you have access to a win32 machine and time
to debug?
bz: Well, this works for me... tried steps for comment 6
I'm not seeing this with today's build (Windows 2002 - BuildID: 2003013008). I
don't have WinZip configured as the helper application for zip files however (we
use PKZIP). I am able to save all of the links listed in this bug properly (no
.x extension).
Attached file Working regmon log.
Here is the regmon log from my machine, where I am not seeing this problem.
I'd like to confirm this bug on 1.3b build 2003021008. I can't upgrade to see if
it exists in newer versions in the next few days, though
with 1.3 final it hasnt happened for 2 weeks on me
not using trunk builds cause they messed up on me lately
futuring pending some idea as to what's going on.  The help of someone on
Windows who can reproduce and has time to debug would be much appreciated.
Keywords: helpwanted
Priority: P1 → P2
Target Milestone: mozilla1.4alpha → Future
The problem seems to have gone away with 1.4a (20030401). Two things that may be
relevant given comments in the thread. 1. I also do not use WinZip, rather I use
UltimateZip (free and better ;). 2. In 1.4a (20030401), behavior is as expected,
however, when the save dialogue box appears asking where to save the .zip file,
there is nothing listed at all under File Type. There is nothing there even in
the drop down (the list is empty). I'm not sure if this is a related issue (not
a programmer, unfortunately) but I figured I'd mention it.
*** Bug 203646 has been marked as a duplicate of this bug. ***
*** Bug 204030 has been marked as a duplicate of this bug. ***
A normal download (so not Save As...) bus just downloading a .zip with Phoenix /
Firebird (nightly) also adds .x!
There's nothing I can do with this bug, since I have no Windows system to test
on and I don't see, based on the logs in here, how it could possibly be

In any case, I bet rewriting all this code like we need to will fix it.
Assignee: bz-bugspam → nobody
Depends on: 147679
-> the other nobody
Assignee: nobody → nobody
Flags: blocking1.4+
Clearing blocking1.4b+. Only drivers set that. marijndejong: please don't do
that again, only use the ? flag.
Flags: blocking1.4+
Set Blocking 1.4 to ? as instructed by Christian Biesinger  
Flags: blocking1.4?
wfm build id 2003050714

every test case i've tried is working fine. note: i do not have winzip or any
other .zip handling app i use winXP .zip handler instead
Without more info and with the low-visibility and user impact of the problem,
not goign to block 1.4 on this. THat's not to say we wouldn't consider a patch
if someone figures it out.
Flags: blocking1.4? → blocking1.4-
Seeing that blocking 1.4 has been denied, let me explain a bit about this bug.

On three different systems with several different phoenix builds, saving a .zip
file adds .x to the filename. Any user who tries to open the zipfile with any
piece of software (windows xp zip handling, winzip, winrar) will be unable to do
so on the files downloaded with Phoenix (or mozilla). Therefore any user trying
to switch from Internet Explorer to Phoenix / Mozilla on a windows platform will
find the downloading function unusable unless they know how to manually change
the file extention. (And from my experience most users don't know this ;-)

* So please fix this bug quickly so I can install Phoenix on my grandfather's pc :-D
mozilla aint just adding a .x to it ... it somehow makes up a new mime type as well
mgabriel: er? files on a hard disk have no mime type, not on windows at least...
well, its add a new entry to mozillas helper applications list ...
even in 1.4beta?
didnt reproduce it for quite a while, i stopped using mozilla for downloads,
cause this and the .tar.gz.tar bug was too annoying. will try trunk nightly for
a while and see if i can reproduce it
again wfm using 2003051216
*** Bug 207423 has been marked as a duplicate of this bug. ***
In the 'Helper Applications' thing in the 'Preferences' menu the is a MIME type
application/x (at least it was for me). I clicked on edit button and changed the
file extension to ".zip"and the problem did go away.
thats what im saying the whole time, the point is where and why does mozilla add
that, CAN mozilla add that by itself anyway ?
Wouldn't 1.4 with the MIME already changed solve the problem?
Hmm?  application/x was never mentioned before now... are people who are seeing
this problem seeing such an entry in their helper app preferences?  I thought
the problem was that there was an application/zip entry with a ".x" extension
that came from somewhere...
Either it was an application/x or an application/zip with the extension being x

I forgot which one it was after I changed it correctly, but I'm more inclined to
the last one.

In the helper application thing (that mention zip)I have these also:
'application/x-zip' (the extension is correcly zip), 
'application/x-zip-compressed' (also zip extension) and 'application/zip' (that
had the extension x that I changed to zip).
I think I have found out how to reproduce this behaviour.  There is [at least] 
one website I have found whilst troubleshooting this problem (with Mozilla/5.0 
(Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401) that ends up 
with ".x" being appended to every .zip file.

To cause this bug visit the url (Warning: 
popups/warez/porn adverts/etc ((note: I an not related in anyway with this 
site, it is the only site I have found that can reproduce this bug with)), and 
click the "download the file" button.  If you select save to disk in mozilla, 
and there is no helper app associated with the "application/zip" mime type, 
then one will be created.  Note that the above url ends in ".x": the helper app 
entry created for "application/zip" will be associated with the ".x" extension 
and not the ".zip" extension.

Here is the HTTP request:
POST /d.x HTTP/1.0
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) 
Accept-Language: en
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 34


And here is the [head] of the response:
HTTP/1.0 200 OK
Date: Wed, 11 Jun 2003 12:27:37 GMT
Server: Apache/2.0.43 (Unix) PHP/4.2.3
Accept-Ranges: bytes
X-Powered-By: PHP/4.2.3
Content-Disposition: attachment;
Content-Transfer-Encoding: binary
Content-Length: 20022
Pragma: no-cache
Content-Type: application/zip

It appears that the script on that website (d.x) is a PHP application serving 
files, but the .x extension in the url confuses mozilla into incorrectly 
appending it to the downloaded file.  As the helper app entry that is created 
is associated with ".x", any files downloaded in the future with a mimetype 
of "application/zip" will have .x appended to their filename.
Ah, hmm.. that would do it, yes....  Not sure what the right course of action is
there -- we already have some code to treat urls with a query string or POST
data differently; we may want to expand on that a bit.

biesi? Got time to look into this?
sorry, not in the next three weeks
I notice this bug a lot.  It is unfortunate that it did not get blocking 1.4
approval.  This happens not only on zip files but also on .torrent BitTorrent
files sometimes.
*** Bug 210241 has been marked as a duplicate of this bug. ***
Attached file PHP Testcase
put this file on a php-capable server to test. instructions contained in the
actually the instructions in the testcase are not quite sufficient. after
submitting the form, you also have to save the file somewhere, i.e. you must not
click cancel in that dialog, because if you do that no entry in helper apps will
be created (I think)
taking bug.

Note 1: The url did not work for me, so I craeted the testcase based
on the http headers shown here
Note 2: This patch does not help you if you already have an entry for
application/zip in your helper apps preferences, so you should manually remove it.
Assignee: nobody → cbiesinger
Priority: P2 → P1
Target Milestone: Future → mozilla1.5alpha
Attachment #126711 - Flags: review?(bzbarsky)
Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

r=me.  Excellent.
Attachment #126711 - Flags: review?(bzbarsky) → review+
Attachment #126711 - Flags: superreview?(darin)
Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

>Index: uriloader/exthandler/nsExternalHelperAppService.cpp

>+NS_IMETHODIMP nsExternalHelperAppService::DoContent(const char *aMimeContentType,
>+                                                    nsIRequest *aRequest,
>+                                                    nsISupports *aWindowContext,
>+                                                    nsIStreamListener ** aStreamListener)
> {
>+  // Get some stuff we will need later
>+  nsCOMPtr<nsIChannel> channel = do_QueryInterface(aRequest);
>+  if (channel) {
>+    nsCOMPtr<nsIURI> uri;
>+    channel->GetURI(getter_AddRefs(uri));

so, why not make DoContent take a nsIChannel instead?  what's the point
of having it pass around nsIRequest instead?
darin: bz wanted to make that function be similar to
nsIURIContentListener::DoContent, and that one takes an nsIRequest
This is an alternative testcase; easier to use but windows-only
Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

ok, sr=darin
Attachment #126711 - Flags: superreview?(darin) → superreview+
thanks for the reviews; checked in

Checking in uriloader/base/nsURILoader.cpp;
/cvsroot/mozilla/uriloader/base/nsURILoader.cpp,v  <--  nsURILoader.cpp
new revision: 1.114; previous revision: 1.113
Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
new revision: 1.195; previous revision: 1.194
Checking in uriloader/exthandler/nsIExternalHelperAppService.idl;
/cvsroot/mozilla/uriloader/exthandler/nsIExternalHelperAppService.idl,v  <-- 
new revision: 1.12; previous revision: 1.11
Closed: 21 years ago
Resolution: --- → FIXED
Blocks: stable1.4
Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

a=mkaply for 1.4.1
Attachment #126711 - Flags: approval1.4.x? → approval1.4.x+
Please add keyword fixed1.4.1 when this is checked in
Flags: blocking1.4- → blocking1.4.x+
Checked in on:

Checking in uriloader/base/nsURILoader.cpp;
/cvsroot/mozilla/uriloader/base/nsURILoader.cpp,v  <--  nsURILoader.cpp
new revision:; previous revision: 1.110
Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
new revision:; previous revision:
Checking in uriloader/exthandler/nsIExternalHelperAppService.idl;
/cvsroot/mozilla/uriloader/exthandler/nsIExternalHelperAppService.idl,v  <-- 
new revision:; previous revision: 1.11
Keywords: helpwantedfixed1.4.1
*** Bug 218808 has been marked as a duplicate of this bug. ***
Blocks: 224532
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.