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

RESOLVED FIXED in mozilla1.5alpha


16 years ago
3 years ago


(Reporter: samdu, Assigned: Biesinger)



Windows XP
Dependency tree / graph
Bug Flags:
blocking1.4.1 +

Firefox Tracking Flags

(Not tracked)



(7 attachments)



16 years ago
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

Comment 2

16 years ago
same here 2003011713 trunk win2k, very annoying
Ever confirmed: true
mgabriel@geekworx.de, is ".x" mapped as an extension for zip files on your
Windows install?

Comment 4

16 years ago
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....

Comment 6

16 years ago
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
(http://www.sysinternals.com/ntw2k/source/regmon.shtml) while you do that?  I'd
love to see the registry access log...

Comment 8

16 years ago
Created attachment 112044 [details]
Regmon Log

Comment 9

16 years ago
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?

Comment 11

16 years ago
nope, too dumb and too poor for it
ok..  taking this while I investigate...

Michael, you say it's a problem for the sourceforge.net 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 sourceforge.net?

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

Comment 14

16 years ago
Created attachment 112111 [details]

Comment 15

16 years ago
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?

Comment 19

16 years ago
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....

Comment 21

16 years ago
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 ?

Comment 22

16 years ago
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....)

Comment 24

16 years ago
Created attachment 112839 [details]
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

Comment 27

16 years ago
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).

Comment 28

16 years ago
Created attachment 113213 [details]
Working regmon log.

Here is the regmon log from my machine, where I am not seeing this problem.

Comment 29

16 years ago
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

Comment 30

16 years ago
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

Comment 32

16 years ago
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. ***

Comment 34

16 years ago
*** Bug 204030 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
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


16 years ago
Flags: blocking1.4+
Clearing blocking1.4b+. Only drivers set that. marijndejong: please don't do
that again, only use the ? flag.
Flags: blocking1.4+

Comment 39

16 years ago
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-

Comment 42

16 years ago
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

Comment 43

16 years ago
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...

Comment 45

16 years ago
well, its add a new entry to mozillas helper applications list ...
even in 1.4beta?

Comment 47

16 years ago
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. ***

Comment 50

16 years ago
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.

Comment 51

16 years ago
thats what im saying the whole time, the point is where and why does mozilla add
that, CAN mozilla add that by itself anyway ?

Comment 52

16 years ago
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...

Comment 54

16 years ago
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).

Comment 55

16 years ago
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 http://www.cracks.am/d.x?210 (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
Host: www.cracks.am
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
Referer: http://www.cracks.am/d.x?842
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; filename=68000_Assembler.zip
Content-Description: 68000_Assembler.zip
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

Comment 58

16 years ago
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.

Comment 59

16 years ago
*** Bug 210241 has been marked as a duplicate of this bug. ***
Created attachment 126710 [details]
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)
Created attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests
taking bug.

Note 1: The cracks.am 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 65

16 years ago
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
Created attachment 126787 [details]
PHP testcase, alternative

This is an alternative testcase; easier to use but windows-only

Comment 68

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Blocks: 211307
Attachment #126711 - Flags: approval1.4.x?
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: helpwanted → fixed1.4.1

Comment 73

16 years ago
*** Bug 218808 has been marked as a duplicate of this bug. ***


15 years ago
Blocks: 224532
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.