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

VERIFIED FIXED

Status

SeaMonkey
UI Design
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: bz, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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

Comment 1

17 years ago
this bug is for me. 
Assignee: pchen → mscott
(Assignee)

Comment 2

17 years ago
Created attachment 41287 [details] [diff] [review]
the fix
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.
(Assignee)

Comment 4

17 years ago
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
(Assignee)

Comment 8

17 years ago
Created attachment 41361 [details] [diff] [review]
fixes wrong variable name
(Assignee)

Comment 9

17 years ago
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
(Assignee)

Comment 11

17 years ago
this has been fixed. 
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Keywords: verifyme
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.