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

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

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

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

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]

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.

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

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.

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

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

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

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.

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

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.

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.

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?

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

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.

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.

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.

New bug filed for empty mime type string is bug 84543

changing status whiteboard to fix in hand

r=pink

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.

adding alecf to cc list for possible sr

sr=alecf

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

fixed checked into trunk

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