Closed Bug 49787 Opened 24 years ago Closed 23 years ago

Advanced users should be able to manually type path in super help app dialog

Categories

(SeaMonkey :: UI Design, defect, P5)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: bugzilla, Assigned: law)

References

(
URL
)

Details

(Keywords: helpwanted) 

* OVERVIEW:
  
  Advanced users who'd rather not deal with a file picker dialog have no way to
  manually type the path to the helper app of their choice.

* STEPS TO REPRODUCE:

  (1) Go to the URL above.
  (2) In the helper app dialog that appears, click Open using and note that the
      textfield remains readonly.

* ACTUAL RESULTS:

   Users must press the Choose... button and navigate through the file picker
   to find the helper app they wish to use.

* EXPECTED RESULTS:

   Advanced users should be able to directly type a path to the helper app.
   When the Open using radio button is checked, the textfield should not be
   readonly/gray.  Otherwise, if Save to disk is checked, the textfield should
   be readonly/gray (to match the behavior of the Choose... button)

* TESTED ON:

  2000082108 win98
*** Bug 58177 has been marked as a duplicate of this bug. ***
*** Bug 60948 has been marked as a duplicate of this bug. ***
I'll spend some time this weekend looking into this....
Nominating ('cause we have to deal with this).

This is kind of a tough nut.  Most of the time, this field does not contain the
name of a file (it has the "name" of an application, like "Microsoft Word" or
"WinZip").  What if the "name" of the application were "rm.exe".  After the user
types something, how do we tell the file name from the application name?

The other thing is that file names aren't unique (on Mac) so if we process the
contents of the input field, we have to deal with that.  Currently, the dialog
relies on the underlying nsIFile (which is unique).
Keywords: nsbeta1
Yeah, I was wondering about that myself the other day (re: sometimes the field 
containing an application name and other times a path).  I think that field 
should only contain the path, and the app title should be displayed 
separately.  Users are accustomed to textfields containing only paths when 
they're next to `Browse...' buttons (that should probably say `Browse...', not 
`Choose...'), and it's confusing for one field to contain two different types 
of data.
I agree w/ blake, the appname should be separated from the app path.
I'd like us to show an app icon for the app.

And I'd like that app icon to be a drop target esp for macos.

Make the field editable everywhere it makes sense. I think it'd even be ok to 
make the field invisible on macos.
We shouldn't even show a filepicker. We should show an application picker, like 
Explorer does on Windows and like the Finder does on Mac OS in the same 
situation -- a list of applications, with icons, to choose from, and an 
`Other ...' button in case the application we want isn't in the 
registry/desktop database.

But providing for typing the filename by hand? ... That's *so* 1980s.
Forgot to add ... The exception, of course, is Linux/Unix, where you don't have 
a global list of apps on the system. In that case you would still have the 
filepicker, but the filepicker allows for typing of the exact pathname on 
Linux/Unix anyway.
Note for the person that implements the Nav Services file picker with an 
application-only file filter: please let me choose aliases to applications, as 
well as the applications themselves.

cc: pchen because he owns Internet Config bugs on Mac OS. Perhaps we can defer 
to its UI?

I'm afraid to say Mac OS X seems to allow you to type in paths to apps in 
various dialogs. How very 1970s...
Just like we have a nsIFilePicker for picking files do we have an XP abstraction
we can invoke for bringing up an application picker? I'd be more than happy to
modify code to invoke that if we've got it. 
*** Bug 64986 has been marked as a duplicate of this bug. ***
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
nav triage team:

Nice to have, but won't get to this now. Removing nsbeta1+, marking future and p5
Priority: P3 → P5
Target Milestone: --- → Future
nav triage team:

No, really, removing nsbeta1+ so that it doesn't show up on the radar
Whiteboard: nsbeta1+
Paul and Eric:  Are you SURE that you want to leave the enabling of existing 
disabled interface items as "P5" and "Future"?

Eric:  I am concerned that the helper app bugs are not being addressed anywhere 
near in proportion to their representation in recent user feedback.  Do you 
have the same impression?
I'd like to second that. The effect of this bug is actually very
annoying. E.g. if you want to read Adobe Acrobat documents with
Mozilla, on loading a .PDF file the browser asks what application
to start. Due to this bug, you have to navigate through a file picker
dialog instead of typing in the path to acroread. Because of
XUL, it takes some time on my PC for the new dialog to appear.

This would be bearable if there wasn't bug 48948 which prevents
the selected viewer app path to be saved for file type .PDF -
which in turn forces the user to repeat the painful procedure every
time he choses to view a PDF file.

So this bug causes discomfort in the every-day use of the UI
and a solution would mean a major enhancement for all users
that use Mozilla to view "external" file types like .doc,.pdf,.ps
MichaelL: Eric Krock is on sabbatical, and asks you be informed of his issues.

I am concerned that the helper app bugs are not being addressed anywhere 
near in proportion to their representation in recent user feedback.  Do you 
have the same impression?

Please review the comments on this and other helper app bugs requiring work 
on preferences component tasks.  Thank you.
Fixed as part of bug 52454.
Depends on: 52454
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla0.9
Spam: new helper app dialog not making mozilla0.9, unfortunately.
Target Milestone: mozilla0.9 → mozilla0.9.1
as discussed in nav team meeting, moving P4 and P5 nsbeta1+ bugs to Future.
Keywords: helpwanted
Target Milestone: mozilla0.9.1 → Future
Now fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
vrfy fixed: can now type in the "Open with Application" textfield, after
selecting the "Use a different action for this file" radio button.

2001.05.08.09, winnt comm
2001.05.08.08, mac comm
debug linux mozilla from 7pm-ish tonight
Status: RESOLVED → VERIFIED
/me grumbles about users typing in paths on mac
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.