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

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+

nav triage team: Nice to have, but won't get to this now. Removing nsbeta1+, marking future and p5

nav triage team: No, really, removing nsbeta1+ so that it doesn't show up on the radar

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.

Spam: new helper app dialog not making mozilla0.9, unfortunately.

as discussed in nav team meeting, moving P4 and P5 nsbeta1+ bugs to Future.

Now 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

/me grumbles about users typing in paths on mac