From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22smp i686) BuildID: 20001026 (sorry, there's no build ID on the window any more! (-; ) Whenever selecting a file that Mozilla can't view (or doesn't know how to handle), the "Downloading" dialog appears. If 'Open using' is selected, the edit box is not activated. Reproducible: Always Steps to Reproduce: 1. Select any unknown file type (eg, the i386 Linux nightly build from the Mozilla home page or the above URL.) 2. Select the 'Open using' radio button 3. Attempt to enter text into the edit box Actual Results: Nothing occurs. (The (lack of) reaction of the edit box is the same as when 'save to disk' is selected, suggesting that it's not being activated.) Expected Results: Allow me to type into the editbox! I can't tell if there's a functionality problem behind this cosmetic problem, because 'Open using' is generally just broken. (see bug 57810 ). however, if one uses the filepicker (selects 'choose...'), the results of the selection show up in the edit box. (The application is not invoked, and the edit box is still not editable.)

mscott/law, is this field supposed to be readonly? there's a Choose button that's activated when clicked, but the field remains readonly --the user's only choice is to select an app from the resulting file picker (after clicking the Choose button).

dup of 49787 *** This bug has been marked as a duplicate of 49787 ***

It works that way on purpose (read-only text field), for a couple of reasons: 1. The contents aren't always a file name (e.g., a .doc file will likely say "Word" while the executable is something like C:\Program Files\Microsoft\Office97\winword.exe). It is somewhat confusing to let them type over "Word." 2. The data is maintained as an nsILocalFile but you can't reliably type in one of those (e.g., on Mac, the file name string can be ambiguous). If we let the user type in that field, knowing whether the internal nsILocalFile object matches what's in the input field is problematic. Those are kind of lame excuses, probably.

Verified, this is a duplicate of bug 49787 "Advanced users should be able to manually type path in super help app dialog."