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

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P2)

Description

[sairuh (rarely reading bugmail)]

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

recipe:
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
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-05-08-09-trunk/ 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,
however.

4. click OK.

results:
* 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.

Comment 1

[Bill Law]

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.

Comment 2

[sairuh (rarely reading bugmail)]

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.

Comment 3

[Paul Chen]

nav triage team:

Sounds like something is really broke. nsbeta1+ and mozilla0.9.1

Comment 4

[Viswanath Ramachandran]

nav+pdt triage: moving to mozilla0.9.2. 

Comment 5

[Paul Chen]

nav triage team:

REALLY moving to mozilla0.9.2

Comment 6

[Skewer]

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.

Comment 7

[Bill Law]

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.

Comment 8

[Bill Law]

OK, marking resolved.  Please see my previous comments and re-open if problems 
still exist.

Comment 9

[sairuh (rarely reading bugmail)]

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.