Closed Bug 79231 Opened 24 years ago Closed 23 years ago

Not filling in default action with name of helper app

Categories

(SeaMonkey :: UI Design, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: mscott, Assigned: bugzilla)

References

Details

(Whiteboard: need a=)

Attachments

(1 file)

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.
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.
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...
OS: Windows 2000 → All
Hardware: PC → All
filed bug 79631 to cover 2b above.
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).
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
Keywords: review
Blocks: 79356
awesome. sr=mscott
claudius, here's the bug you were asking about.
could this be reviewed/checked into the trunk now? thx!
Keywords: mozilla0.9.2
nav triage team:

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

Oh yeah, r=pchen
Keywords: nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
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=
Assignee: law → blake
Whiteboard: need a=
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 86751 has been marked as a duplicate of this bug. ***
vrfy fixed on mac, winnt and linux with 2001.06.21.xx comm bits.

thx for checking this in, blake.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: