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

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[Mario Salzer]

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.

Comment 1

[Brendt Hess]

Attachment: 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

[Brendt Hess]

Attachment: Result window for DL manager

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

Comment 3

[Scott]

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

[Scott]

Attachment: windows "open with" dialog

Comment 5

[John Mellor (Jomel)]

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

Comment 6

[Angelo]

Attachment: Open with dialog

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

Comment 7

[Angelo]

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

Comment 8

[Akkana Peck]

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

Comment 9

[Gary Lawrence Murphy]

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

Comment 11

[Corey Woodworth]

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

Comment 12

[[:Aleksej]]

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

Comment 13

[Edd]

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

Comment 14

[John Vivirito]

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

Comment 15

[Thomas Ibbotson]

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

[Micah Gersten]

Is this a dupe of Bug 397700?

Comment 17

[Akkana Peck]

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.

Comment 18

[Patrick O'Keeffe]

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

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 21

[Ruby Shaw]

Attachment: same problem

Thanks from clinuninin1979.