Closed Bug 79631 Opened 24 years ago Closed 24 years ago

app launched & file downloaded when mime-type is Save to Disk [no file picker appears]


(SeaMonkey :: UI Design, defect, P2)

Windows NT


(Not tracked)



(Reporter: bugzilla, Assigned: law)



spun off from bug 79231... found using 2001.05.08.09 comm bits on winNT.

1. create the following mime-type in the Helper Applications prefs panel:
   Description: Zip
   mime type: application/zip
   extension: zip
   "ask me before opening downloaded files of this type" is selected
   action: save to disk [will need to save the mime-type, then edit to actually
set this part].

2. click on a link to a .zip file, eg: go to and click on any
of the zip files there.

3. the new downloading/helper app dialog appears. "Use default action" is
selected, but the textfield is blank [bug 79231]; do not change the settings,

4. click OK.

* download progress dialog appears, and the file is saved to the temp [default]
directory, C:\TEMP\[garbage-name].zip
* a split second after the download progress dialog appears, the WinZip
application appears.
Keywords: nsbeta1
Try changing the MIME type to application/x-zip-compressed and see if that fixes
things.  If so (and I think it will), then this is a dup of bug 78943.
Blocks: 78106
i changed the mime type to application/x-zip-compressed, and this still happens.

adjusted summary. what's happening --in addition to downloading to TEMP and
opening the WinZip app-- is that the file picker to choose the saving location
never appears.
Summary: app launched & file downloaded when mime-type is Save to Disk → app launched & file downloaded when mime-type is Save to Disk [no file picker appears]
nav triage team:

Sounds like something is really broke. nsbeta1+ and mozilla0.9.1
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
nav+pdt triage: moving to mozilla0.9.2. 
nav triage team:

REALLY moving to mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I'm seeing this in 2001052404 Win98.

Procedure: When downloading a zip file, set the default action as Save to Disk.
The next zip file you download will have a blank default action and open into
the default program.
OK, this is working for me (of course :-).

These are tricky bugs to report and work on.  You have to be very careful to
state precisely what URL you were downloading, what mime-type your pref entries
have, and what mime types show up in the dialog.

The original report is accurate I believe, and is working as designed.  Since
the URL in question is ftp, there is no content type.  So we determine the
content-type based on the file extension.  For some reason,
.zip->application/x-zip-compressed.  Since there's no helper app pref entry for
that MIME type, you get the system-defined default, which is to run WinZip.

Changing the entry to application/x-zip-compressed *should* work, in this case
(and I verified that it does work for me), but it won't work for .zip files
downloaded from other places (i.e., via http: where the content-type is most
likely application/zip).

Just to further complicate things, for http: (application/zip), if we don't find
a helper app pref entry, then we errorneously put up the dialog with
"application/x-zip-compressed" in it.  That entry won't work the next time (but
it will if you download a .zip via ftp).  This is bug 78943.

So Skewer, I suspect your problem is bug 78943.

Sarah, I suspect you were seeing "correct" (albeit unwelcome) behavior
originally, and probably tried a different (http:) link after trying my
suggestion to change the MIME type to application/x-zip-compressed.  Could that
be the case?

I *think* all bases will be covered if you set up helper app pref entries for
*both* application/zip and application/x-zip-compressed.  If you have both and
still see problems, let me know.
OK, marking resolved.  Please see my previous comments and re-open if problems 
still exist.
Closed: 24 years ago
Resolution: --- → WORKSFORME
bill, thx for the explanation!

i changed the mime to be application/x-zip-compressed, and when i click a .zip
file from ftp, it works just dandy. so verifying this. [was using 2001.06.04.11
trunk and branch bits.]

yes, i still see the behavior i had originally reported here if i click a .zip
file from http --so, good to know that's already covered by bug 78943.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.