Closed Bug 79837 Opened 23 years ago Closed 23 years ago

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

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: sfraser_bugs, Assigned: paulkchen)

References

Details

(Whiteboard: fix in hand)

Attachments

(2 files)

screenshot w/bad descrp and unselected/active radiobuttons
17.60 KB, image/jpeg
Details
disable mime check only if file extension passed in
937 bytes, patch
Details | Diff | Splinter Review 
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.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
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].
Keywords: nsCatFood → nsCatFood+
Whiteboard: estimate 2 days, eta 6/15
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.
Summary: Downloading dialog not correctly filled in sometimes → Downloading dialog not correctly filled in sometimes [+ Set Default button broken]
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.
Whiteboard: estimate 2 days, eta 6/15 → fix in hand
New bug filed for empty mime type string is bug 84543
Whiteboard: fix in hand → estimate 2 days, eta 6/15
changing status whiteboard to fix in hand
Whiteboard: estimate 2 days, eta 6/15 → fix in hand
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.
Blocks: 84395
adding alecf to cc list for possible sr

sr=alecf
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
fixed checked into trunk
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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].
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: