79837 - Downloading dialog not correctly filled in sometimes [+ Set Default button broken]

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Simon Fraser [no longer active]]

When downloading a ".sit" file, sometimes I see that the downloading dialog does 
not get correctly filled in. The dialog says

"You have chosen to download a file of type: "#1" [#2] from #3", and no radio 
buttons in the dialog are chosen by default.

This works fine on another machine, so I suspect some kind of machine-specific 
issue, perhaps related to Internet Config (though I do have .sit mappings in IC).

Comment 1

[Bill Law]

Paul, I suspect that there's an exception occuring inside the onload handler for
the dialog which is preventing the content from being initialized.  I don't have
any idea why that would be, though...

Comment 2

[Simon Fraser [no longer active]]

It looks like this.mLauncher.MIMEInfo.MIMEType is bad

Comment 3

[Simon Fraser [no longer active]]

Ah, I think I know what's happening.

I think we're getting the first matching entry for ".sit" out of Internet Config,  
which has an empty MIME type string, so the GetMIMEType call on nsMIMEInfoImpl is 
returning NS_ERROR_NOT_INITIALIZED.

So we need to fix 2 things here:
1. Make the download dialog JS robust to errors returned here.
2. Make the IC code iterate through *all* MIME entries which match the file 
extension, and find the "best" one (where the best one is the one with most info, 
e.g. non-null MIME type).

Comment 4

[Simon Fraser [no longer active]]

Note: this same issue causes the 'Set Default' button to not work, giving a JS 
error:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code: 
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.MIMEType]"  nsresult: 
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: Lion:Mozilla 
trees:Tree:src:mozilla:dist:viewer_debug:Components:nsHelperAppDlg.js :: 
anonymous :: line 448"  data: no]

Comment 5

[Bill Law]

I think the patch in bug 78943 would help.  That ensures that the MIMEInfo
object's MIMEType matches the actual content's MIMEType as reported by the
server (which, worst case would be something like application/unknown-content,
or something like that).  I'm not sure that would cover all cases, though.
Probably nsMIMEInfoImpl should default to something reasonable.

That still leaves the problem of making sure we pick the "best" match from IC.
I'll let Paul deal with that issue.

Comment 6

[sairuh (rarely reading bugmail)]

interesting. sometimes when i fill out the myEbay login page
[http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?MyEbayLogin] --or, sometimes trying
to load that page-- i get the helper app dialog which says "You have chosen to
download a file of type: "#1" [#2] from #3".

has anyone else encountered this, either when filling out/going to a login page,
or in situations where you thought you weren't explicityly downloading
something? just wondering...

Comment 7

[Bradley Baetz]

I get this error when a page doesn't send a content-type header back - I
originally saw this when actually connecting to http://ftp.mozilla.org:21
(verified using netcat)

sairuh - theres another bug on ebay not working, and that may be related.

Comment 8

[sairuh (rarely reading bugmail)]

bradley, found it: bug 80544 [i had fallen off the list there].

Comment 9

[sairuh (rarely reading bugmail)]

reproduced this on mac [modern theme, fwiw], using 2001.06.06.03-branch comm
bits.

1. went to http://law.mcom.com/download.html [sorry about the internal site].
2. in the "pretty big file (7M)" section, single-clicked on the "via http" link.

result: in the downloading/helper app dialog, none of the radiobuttons are
selected, and none of the fields are prefilled. the description at the top reads

   You have chosen to download a file of type: "#1" [#2] from #3

Comment 10

[sairuh (rarely reading bugmail)]

almost forgot: the link i clicked points to an .exe file, bigger.exe.

Comment 11

[sairuh (rarely reading bugmail)]

feh, forgetful me: the last two comments above are referring to the *mac* build.

i'm wondering if this is mac-only? pls let me know if anyone else has seen this
on other platforms. i also tested on winNT and linux, and didn't see "#1" [#2]
from #3 issue described here.

test results:
------------
a. using the same test case [described in my last two comments] on winNT,
2001.06.06.11-branch comm bits: when i don't have a helper app defined for
application/octet-stream, i simply get the File Save dialog [file picker] for
bigger.exe. expected behavior, iirc.

b. on winNT 2001.06.06.11-branch comm bits when i *do* have a helper app defined
for application/octet-stream: the download/helper app dialog does appear. i have
it set to save to disk by default [sure enough, the radiobutton for "Use default
action..." is selected, and its textfield is prefilled with "Save to disk"]. the
description at the top reads:

  You have chosen to download a file of type: "application/octet-stream"
  [application/octet-stream] from http://law.mcom.com

again, expected behavior.

c. on linux 2001.06.06.04-branch comm bits, when i don't have a helper app
defined for application/octet-stream, i get a similar dialog to (b): "Use
default action..." is selected, and its textfield is prefilled with "Save to
disk". however, the description at the top is somewhat different:

  You have chosen to download a file of type: "application/octet-stream"
  from http://law.mcom.com

methinks this is expected behavior.

d. on linux again, similar to (c) but this time i do define a helper app to deal
with application/octet-stream files with .exe extensions [i just set it to save
to disk, for simplicity]. the radiobutton and textfield settings are the same as
(c), but the description is a bit different:

  You have chosen to download a file of type: "Exe octet-stream files"
  [application/octet-stream] from http://law.mcom.com

again, this seems expected behavior to me.

Comment 12

[Simon Fraser [no longer active]]

Read up about why you get the "#1 [#2] from #3" stuff on Mac in some situations 
only (empty MIME type string in Internet Config).

Comment 13

[sairuh (rarely reading bugmail)]

a couple mores things i noticed while testing this on mac --however, i'm not
sure if it's due to this bug:

* even though none of the radiobuttons are selected, they all appear active
[will attach screenshot].

* clicking the Set Default button does not bring up the helper app editor
--whether or not i've selected the "Use default action..." radiobutton, for that
matter.

Comment 14

[sairuh (rarely reading bugmail)]

more observations [apologies for the noise, but i'm doing this to help narrow
down/define good test cases]:

* also see this bug [again, mac-only] when doing a ftp download of an .exe file,
eg, ftp://ftp.mozilla.org/pub/mozilla/nightly/ --go into a dir that has an .exe,
then single-click it to see this.

* workaround for the Set Default issue here: instead, define the helper app via
the Helper Applications panel in the Preferences dialog. encountered some
strangeness not being able to remove the helper app, but will file that
separately.

Comment 15

[sairuh (rarely reading bugmail)]

Attachment: screenshot w/bad descrp and unselected/active radiobuttons

Comment 16

[sairuh (rarely reading bugmail)]

my brain is off: the Set Default button is covered here. /me re-read's sfraser's
2001-05-09 15:49 comment. is that worthy of a separate bug?

Comment 17

[Simon Fraser [no longer active]]

I don't think so; it's the same underlying problem.

Comment 18

[sairuh (rarely reading bugmail)]

okay, good to know!

anyhow, the bug for not being able to [easily] remove the
application/octet-stream entry from the Helper App pref panel is bug 84395.

Comment 19

[Paul Chen]

Ok, I've got a fix for .exe that Sairuh mentioned. I put in code to turn off
mime type matching for unknown and octet stream types, so we then fall back on
file extension mapping. But, doh, we don't get that from uriloader. So the fix
is to turn it off when the file extension passed in is non null.

I also created code to try and find the "best" fit IC entry, but so far, I don't
have a test case that exercises the code.

Comment 20

[Paul Chen]

Attachment: disable mime check only if file extension passed in

Comment 21

[Paul Chen]

Ok, just attached fix. Only disable the mime check if the file extension passed 
in is non null. I did add code to find the best match IC entry, but I can't find 
a test case to test out the code. Therefore, I will fix the obvious bug above 
using this bug and open a new bug about returning an empty mime type.

Comment 22

[Paul Chen]

New bug filed for empty mime type string is bug 84543

Comment 23

[Paul Chen]

changing status whiteboard to fix in hand

Comment 24

[Mike Pinkerton (not reading bugmail)]

r=pink

Comment 25

[Paul Chen]

Just to clarify, the reason we disable mime checking for unknown and octet
stream is mainly for the case where we get octet-stream for a ".bin" file. On
the mac, we don't want to label that as some generic binary file, we really want
to make that file a macbinary file and run it through stuffit expander. Of
course, if we don't have the file extension, we can't tell what the content type
is anyway, thus the reason for the patch.

Comment 26

[Paul Chen]

adding alecf to cc list for possible sr

Comment 27

[Alec Flett]

sr=alecf

Comment 28

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 29

[Paul Chen]

fixed checked into trunk

Comment 30

[sairuh (rarely reading bugmail)]

thx for the fix, pchen! vrfying...

some tests using 2001.06.19.08 comm bits on Mac OS 9.0x:

a. no helper app defined, click .exe file from both http and ftp listings [from
bill's test page].

results:
Description says: You have chosen a file of type: "Untyped Binary Data"
[application/octet-stream] from <path>.


b. no helper app defined, click .bin file from both http and ftp listings [from
http://barebones.com/products/bbedit/bbedit-demo.html].

http results:
Description says: You have chosen a file of type: "Untyped Binary Data"
[application/octet-stream] from <path>.

ftp results:
Description says: You have chosen a file of type: "MacBinary"
[application/x-macbinary] from <path>.


c. no helper app defined, click .sit file from both http and ftp listings [from
http://www.smfr.org/mtnw/downloading.html].

http results [used lull.org link]:
Description says: You have chose a file of type: "StuffIt 5.5 Archive"
[application/x-stuffit] from <path>.

ftp results [used accesscom.com link]:
Description says: You have chose a file of type: "StuffIt 5.5 Archive"
[application/x-stuffit] from <path>.


d. checking radiobuttons and Set Default button: radiobutton aren't all enabled,
and clicking Set Default brings up the New Type dialog.

important note: the actual mime type reported here in these tests are dependent
on how the given servers have been configured to serve out the content [hence
the variation in mimetypes seen].