58177 - text box in "Open using" dialog is not editable

Status: VERIFIED DUPLICATE of bug 49787

(SeaMonkey :: UI Design, defect, P3)

Description

[Brian Teague]

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

Comment 1

[sairuh (rarely reading bugmail)]

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

Comment 2

[Blake Ross]

dup of 49787

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

Comment 3

[Bill Law]

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.

Comment 4

[Hans Peter Groendal]

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