User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 If I click on a tarball or some other application/octet-stream, Firefox allows to download it or open it with an helper application. The default of "/usr/bin/tar" is of course plain stupid when running under X11, but that's not the issue here ;) If I select "Other..." in the "Open with" select box, the _ordinary_ file section box appears. It is impossible to specify an application by name. If I for exmaple would like to use KDEs "ark" instead of the default "/usr/bin/tar" I'm forced to enter "/usr/bin/ark" instead of simply "ark". That's an usability issue. Many apps are already in the $PATH, so there is really no need to depend on the full pathname in this dialog box. Also it would be really helpful to allow free form application names here. Instead of letting Firefox run "/usr/bin/tar" it would make sense to enter "rxvt -rv tar xvzf " (or something that way??) in this box - that would make sense. The current implementation forbids all that. It was better if it allowed both - walking down the full filesys hierarchy into ".../bin/" to select an executable - and let more experienced users just specify the program name. The OS provides other ways to detect if program execution worked or not - it's really unneccessary to check for file existence here and require the full pathname to the run helper application. Reproducible: Always Steps to Reproduce: 1. 2. 3.

The filename is multi-word with spaces, but the Opening box shows only one word - name broken at first space.

This shows the results in the Download Manager window. The filename matches the item in the list.

A similar usability issue exists in Windows, where a normal file browser window is opened when one selects "Open with" and then "Browse..." instead of the standard windows "open with" dialog, which presents the user with a list of programs instead of forcing them to look through folder after folder trying to find the correct file. I didn't want to open a new bug since this issue seems very similar to the one on linux, though the fix is probably different.

Scott: There's a separate bug for the Windows side of this: bug 237079

This is the standard Open with dialog on Gnome, maybe this one should be used

This one should be moved to OS Integration (or at least File Handling) component and should have enhancement severity

Confirming. Something that allows typing in a program name, or lists programs already in the path, would be a lot easier to use even for users geeky enough to know the likely places to look, and a lot less RSI-inducing than the clicks needed to navigate to /usr/bin and /bin and /usr/local/bin and so forth (accessibility hint: typing / brings up a text field, which at least gets us back to the functionality of the previous dialog).

"The current implementation forbids all that. It was better if it allowed both - walking down the full filesys hierarchy into ".../bin/" to select an executable - and let more experienced users just specify the program name." I think you have that backwards: Novice users are far more likely to know they are using the "tar" or "xpdf" program than they are to know which of /usr/bin /bin /usr/local/bin /opt/whatever is holding the binary. Remember: Novices have been lead to think of paths as "folders" not as "name spaces". In the current Firefox, the dialog only allows navigation by one directory at a time, which is a usability nightmare. Even if one knows enough to open a shell and type "which xpdf" you are still left with the many clicks and long pauses to get to that location from the default Desktop -- who here has _ever_ launched _any_ web content with a binary that is located in their home Desktop directory? I suppose what would be optimum is if users could select the target app from their Gnome/KDE menu and drag and drop that link into Firefox to set the application, but I expect that's asking too much. For the interim, I'd be happy if we could go back to the case where I can enter the command directly in an edit box so I can do the "which tar" in a shell and cut and paste.

Amen. I'm really hoping this gets fixed before 3.0 is released.

A related (but different, though some bugs like it have been duped here) bug: bug 370380.

I agree, the dialog should search $PATH. Also I would like to add that when you type a path say, /usr/local/bin, because there are so many files there, it locks up for a long time. Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.9.0.3) Gecko/2008100403 Firefox/3.0.3 Thanks

There hasnt been a recent update on this bug. Is this still a problem in 3.0.7? The Ubuntu bug tracker is tracking this bug at: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/111818

I still have this problem with FF3.5b99 on Ubuntu 9.04. Also I've installed the Beta from an ubuntu PPA which means it has hardly any default programs registered, making the download dialog basically unusable because of this.

Is this a dupe of Bug 397700?

It's certainly related, but bug 397700 seems to be talking about an XDG selector for apps registered with the gnome desktop for a particular mime type, while this bug seems to be about what happens if you want to specify a program by name (in case nothing is registered or you're not running a gnome desktop). I hope the solution to that bug will include a fix for this one as well, but it's not automatic.

This issue extends beyond opening files to, for example, selecting an application to view RSS feeds.