79231 - Not filling in default action with name of helper app

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Scott MacGregor]

Hey Bill,
I just downloaded today's (05/07) release build and your new dialog looks great.
I'm having one problem though.

When I open an attachment up and we get this dialog, we aren't filling in the
text field underneath "Use default Action".

before, we would fill this field in with something like "Real Player" or "Vcard
Manager".  Now I get nothing and I don't know what's going to get executed when
I hit okay.

Comment 1

[Bill Law]

I've seen this now and again, certainly not all the time.  It wasn't clear
exactly which scenario(s) caused this and I decided to put off figuring it out
till later.  I'll have a look.

Comment 2

[sairuh (rarely reading bugmail)]

i see this on all platforms...

however, when i've created a mime-type whose default action is to Save to Disk,
i noticed a couple of things:

1. on linux, the Right Thing occurs, and the "Use default action" textfield says
"Save to Disk". [side note: and clicking OK and saving/downloading does work as
expected, yay!]

2(a). on winNT, the "Use default action" textfield is blank --is this bug 79503,
or something else? kinda strange, since i had *already* created the mime-type
with the action to save to disk. should this be a separate bug?

2(b). [still on winNT, a bit of digression] so, in spite of what the dialog
displays2a, i keep "Use default action" selected and hit OK. result: i'm not
asked *where* to save the file --instead both the download progress dialog
appears [saving to \temp\] *and* the helper app opens [WinZip in this case, even
though i never explicitly set it when i created to mime-type]. i'll file a bug
for this...

Comment 3

[sairuh (rarely reading bugmail)]

filed bug 79631 to cover 2b above.

Comment 4

[Bill Law]

re: 2a

The "use default action" text field being blank is *this* bug :-).  It should
never be blank.  If it's *wrong*, then that might be bug 79503 (more likely, 78943).

re: 2b

Probably application/zip is associated with WinZip in your Windows registry.  So
launching WinZip is the right thing (unless you've overridden that in Prefs; but
watch out for bug 78943 if you try to do that).  So I'm not sure there's a bug
there (again, aside from the explanation being blank, which is this bug).

Comment 5

[Bill Law]

Attachment: Patch (also fixes 79356)

Comment 6

[Bill Law]

Patch fixes this (there was a case where the explanation wasn't being put into 
the document).  This also fixes a JS strict warning (described under bug 79356)l

Comment 7

[Scott MacGregor]

awesome. sr=mscott

Comment 8

[sairuh (rarely reading bugmail)]

claudius, here's the bug you were asking about.

Comment 9

[sairuh (rarely reading bugmail)]

could this be reviewed/checked into the trunk now? thx!

Comment 10

[Paul Chen]

nav triage team:

Check this in. Marking nsbeta1+, p3, and mozilla0.9.3.

Oh yeah, r=pchen

Comment 11

[sairuh (rarely reading bugmail)]

bill's on sabbatical...so passing the buck to blake to check this in [if it's
still good to go].

could we get this checked in for 0.9.2? would rather get it in before the
branching, so we don't have to do both a branch and trunk checkin...

cc'ing asa for a=

Comment 12

[Asa Dotzler [:asa]]

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

Comment 13

[Blake Ross]

Fix checked in.

Comment 14

[sairuh (rarely reading bugmail)]

*** Bug 86751 has been marked as a duplicate of this bug. ***

Comment 15

[sairuh (rarely reading bugmail)]

vrfy fixed on mac, winnt and linux with 2001.06.21.xx comm bits.

thx for checking this in, blake.