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

Status: RESOLVED FIXED

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

Description

[Sam Dunham]

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.

Comment 1

[Matthias Versen [:Matti]]

-> File Handling

Comment 2

[Michael Gabriel]

same here 2003011713 trunk win2k, very annoying

Comment 3

[Boris Zbarsky [:bzbarsky]]

[e-mail], is ".x" mapped as an extension for zip files on your
Windows install?

Comment 4

[Michael Gabriel]

no and neither does mozilla know a helper applicaton for .x

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

[Michael Gabriel]

just trying to download a .zip file eg.
http://unc.dl.sourceforge.net/sourceforge/phpmyadmin/phpMyAdmin-2.3.3pl1-php3.zip
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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

[Michael Gabriel]

Attachment: Regmon Log

Comment 9

[Michael Gabriel]

btw, the download of regmon worked as expected, no .x

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[Michael Gabriel]

nope, too dumb and too poor for it

Comment 12

[Boris Zbarsky [:bzbarsky]]

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_MODULES=nsHttp:5
set NSPR_LOG_FILE=c:\log.txt
mozilla

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...

Comment 13

[Boris Zbarsky [:bzbarsky]]

.

Comment 14

[Michael Gabriel]

Attachment: HTTP Log

Comment 15

[Michael Gabriel]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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...

Comment 17

[Michael Gabriel]

OK

http://www.sysinternals.com/files/ntregmon.zip

http://support.crystaldecisions.com/communityCS/FilesAndUpdates/cr90devwin_en.zip.asp?recDnlReq=Record&dnlPath=cr90devwin_en.zip

FAILS

http://telia.dl.sourceforge.net/sourceforge/tep/tep-pr2.1.zip

http://tep.sourceforge.net/snapshots/tep_snapshot-20030119.zip

http://www.php.net/do_download.php?mr=http%3A%2F%2Fde.php.net%2F&df=php-4.3.0-Win32.zip

http://www.arecom.com/~marms/phpedit.net/download/PHPEdit/IDE/PHPEdit-devel-0.7.1.99-2003-01-23.zip

Comment 18

[Boris Zbarsky [:bzbarsky]]

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:

http://68.20.23.79:8000/~bzbarsky/test/test.zip
http://68.20.23.79:8000/~bzbarsky/test2/test.zip

(these won't work once my IP changes, but should be ok for the next few
hours...).  What happens with those two?

Comment 19

[Michael Gabriel]

first fails, 
second ok

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

[Michael Gabriel]

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

[Michael Gabriel]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

[Michael Gabriel]

Attachment: mimeTypes.rdf

Comment 25

[Boris Zbarsky [:bzbarsky]]

Alright.  No .x there....

pkw?  biesi?  timeless?  does one of you have access to a win32 machine and time
to debug?

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

bz: Well, this works for me... tried steps for comment 6

Comment 27

[Philip K. Warren]

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

[Philip K. Warren]

Attachment: Working regmon log.

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

Comment 29

[Sander Bouwhuis]

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

[Michael Gabriel]

with 1.3 final it hasnt happened for 2 weeks on me
not using trunk builds cause they messed up on me lately

Comment 31

[Boris Zbarsky [:bzbarsky]]

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.

Comment 32

[Sam Dunham]

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.

Comment 33

[Matthias Versen [:Matti]]

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

Comment 34

[noririty]

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

Comment 35

[Marijn de Jong]

A normal download (so not Save As...) bus just downloading a .zip with Phoenix /
Firebird (nightly) also adds .x!

Comment 36

[Boris Zbarsky [:bzbarsky]]

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
happening....

In any case, I bet rewriting all this code like we need to will fix it.

Comment 37

[Dave Miller [:justdave]]

-> the other nobody

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 39

[Marijn de Jong]

Set Blocking 1.4 to ? as instructed by Christian Biesinger  

Comment 40

[William James Dean]

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

Comment 41

[Asa Dotzler [:asa]]

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.

Comment 42

[Marijn de Jong]

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

[Michael Gabriel]

mozilla aint just adding a .x to it ... it somehow makes up a new mime type as well

Comment 44

[Christian :Biesinger (don't email me, ping me on IRC)]

mgabriel: er? files on a hard disk have no mime type, not on windows at least...

Comment 45

[Michael Gabriel]

well, its add a new entry to mozillas helper applications list ...

Comment 46

[Christian :Biesinger (don't email me, ping me on IRC)]

even in 1.4beta?

Comment 47

[Michael Gabriel]

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

Comment 48

[William James Dean]

again wfm using 2003051216

Comment 49

[Matthias Versen [:Matti]]

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

Comment 50

[Ricardo]

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

[Michael Gabriel]

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

[Ricardo]

Wouldn't 1.4 with the MIME already changed solve the problem?

Comment 53

[Boris Zbarsky [:bzbarsky]]

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

[Ricardo]

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

[Gerry Murphy]

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) 
Gecko/20030401
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,
video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
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

ID=842&down_load=Download+the+file-

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.

Comment 56

[Boris Zbarsky [:bzbarsky]]

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?

Comment 57

[Christian :Biesinger (don't email me, ping me on IRC)]

sorry, not in the next three weeks

Comment 58

[NorthMan]

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

[Jesse Ruderman]

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

Comment 60

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: PHP Testcase

put this file on a php-capable server to test. instructions contained in the
file.

Comment 61

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 62

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch: Never store extensions for result of POST requests

Comment 63

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 64

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

r=me.  Excellent.

Comment 65

[Darin Fisher]

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?

Comment 66

[Christian :Biesinger (don't email me, ping me on IRC)]

darin: bz wanted to make that function be similar to
nsIURIContentListener::DoContent, and that one takes an nsIRequest

Comment 67

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: PHP testcase, alternative

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

Comment 68

[Darin Fisher]

Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

ok, sr=darin

Comment 69

[Christian :Biesinger (don't email me, ping me on IRC)]

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
done
Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.195; previous revision: 1.194
done
Checking in uriloader/exthandler/nsIExternalHelperAppService.idl;
/cvsroot/mozilla/uriloader/exthandler/nsIExternalHelperAppService.idl,v  <-- 
nsIExternalHelperAppService.idl
new revision: 1.12; previous revision: 1.11
done

Comment 70

[Mike Kaply [:mkaply]]

Comment on attachment 126711 [details] [diff] [review]
patch: Never store extensions for result of POST requests

a=mkaply for 1.4.1

Comment 71

[Mike Kaply [:mkaply]]

Please add keyword fixed1.4.1 when this is checked in

Comment 72

[Christian :Biesinger (don't email me, ping me on IRC)]

Checked in on:
CVS:  Tag: MOZILLA_1_4_BRANCH

Checking in uriloader/base/nsURILoader.cpp;
/cvsroot/mozilla/uriloader/base/nsURILoader.cpp,v  <--  nsURILoader.cpp
new revision: 1.110.4.1; previous revision: 1.110
done
Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.186.4.2; previous revision: 1.186.4.1
done
Checking in uriloader/exthandler/nsIExternalHelperAppService.idl;
/cvsroot/mozilla/uriloader/exthandler/nsIExternalHelperAppService.idl,v  <-- 
nsIExternalHelperAppService.idl
new revision: 1.11.62.1; previous revision: 1.11
done

Comment 73

[Bill Mason]

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