Closed Bug 89414 Opened 23 years ago Closed 23 years ago

A blank application description leads to weird behavior of the helper app dialog

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bzbarsky, Assigned: mscott)

References

Details

Attachments

(2 files)

After bug 88066 got fixed, if the helper app dialog is spun up with an empty
string for the application description (but a valid and existing nsIFile for the
handler) the following behavior is observed:

1)  The dialog correctly shows the app filled in (based on filename) but the
    "Save to Disk" radio button is selected.
2)  When the "Open Using" radio button is selected by the user the "OK" button
    becomes inactive.

This is _extremely_ confusing to the user.

This bug will naturally disappear if bug 86640 is fixed.
this bug is for me. 
Assignee: pchen → mscott
Attached patch the fixSplinter Review
i cannot seem to repro this [using 2001.07.05.08-trunk comm, linux], but perhaps
i'm misunderstanding it?

here are the steps i took:

1. went to helper apps panel in prefs dialog and created the following type:
  Description: [blank]
  extension: mp3
  mime: audio/mpeg
  app to handle: /usr/bin/xmms
2. clicked on an .mp3 file.

result: helper app dialog appeared w/"Open with xmms" selected, as expected.

i removed the type from the prefs, and tried this again by creating the type
directly from the helper app dialog [via "Advanced"], and got the same result.
that's weird. I was able to see the problem b4 my fix. 

after the dialog comes up click on save then back to open. Is the ok button
still enabled?
yep, the OK button remains enabled. checked with both themes, to see if that'd
make a difference, but it didn't for me...
sairuh: this is not the mime type description we're talking about, but the
application description.   There is no UI to set it by the user; we sort of set
it based on black magic (or registry information) in the MIME code.  At the
moment, all the code we have sets it to something non-empty, so the problem is
kinda hard to reproduce.  You'd need the next-to-last patch from bug 52441,
before I updated it to set a non-empty description.

mscott: your patch fixes the problem for me... but should that test not test for
"this.choseApp" instead of "this.chooseApp"?
boris, thx for the clarification!

i'll add a dependency here [well, at least via a testing perspective... ;)].
Depends on: 52441
your right it should be this.choseApp. I made that change. I could have swore I
reproduced this by creating a mime type with no description. I didn't need fixes
from any other bugs. Hmmm
this has been fixed. 
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
rs vrfy
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: