"open with..." dialog box requires full pathname to choose alternative application




Downloads API
13 years ago
3 years ago


(Reporter: Mario Salzer, Unassigned)


Firefox Tracking Flags

(Not tracked)



(4 attachments)



13 years ago
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:

Comment 1

13 years ago
Created attachment 160420 [details]
The 'Opening <Filename>' box (PC1)

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

Comment 2

13 years ago
Created attachment 160421 [details]
Result window for DL manager

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

Comment 3

13 years ago
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.

Comment 4

13 years ago
Created attachment 163237 [details]
windows "open with" dialog

Comment 5

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

Comment 6

13 years ago
Created attachment 176031 [details]
Open with dialog

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

Comment 7

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

Comment 8

13 years ago
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).
Ever confirmed: true

Comment 9

12 years ago
"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.


11 years ago
QA Contact: ali → download.manager
Assignee: bugs → nobody


10 years ago
Duplicate of this bug: 346870

Comment 11

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

Comment 12

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


9 years ago
Product: Firefox → Toolkit

Comment 13

9 years ago
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: Gecko/2008100403 Firefox/3.0.3


Comment 14

9 years ago
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:

Comment 15

8 years ago
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.

Comment 16

8 years ago
Is this a dupe of Bug 397700?

Comment 17

8 years ago
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.


7 years ago

Comment 18

3 years ago
This issue extends beyond opening files to, for example, selecting an application to view RSS feeds.
You need to log in before you can comment on or make changes to this bug.