Last Comment Bug 259594 - "open with..." dialog box requires full pathname to choose alternative application
: "open with..." dialog box requires full pathname to choose alternative applic...
Status: NEW
:
Product: Toolkit
Classification: Components
Component: Downloads API (show other bugs)
: unspecified
: x86 Linux
: -- normal with 13 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: :Paolo Amadini
Mentors:
: 346870 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-15 09:09 PDT by Mario Salzer
Modified: 2014-10-18 13:39 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The 'Opening <Filename>' box (PC1) (23.62 KB, image/jpeg)
2004-09-28 17:06 PDT, Brendt Hess
no flags Details
Result window for DL manager (16.13 KB, image/jpeg)
2004-09-28 17:08 PDT, Brendt Hess
no flags Details
windows "open with" dialog (67.12 KB, image/jpeg)
2004-10-24 12:12 PDT, Scott
no flags Details
Open with dialog (29.52 KB, image/png)
2005-03-02 05:12 PST, Angelo
no flags Details

Description Mario Salzer 2004-09-15 09:09:35 PDT
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 2004-09-28 17:06:54 PDT
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 Brendt Hess 2004-09-28 17:08:34 PDT
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 Scott 2004-10-24 12:08:16 PDT
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 2004-10-24 12:12:00 PDT
Created attachment 163237 [details]
windows "open with" dialog
Comment 5 John Mellor (Jomel) 2005-02-17 07:10:33 PST
Scott: There's a separate bug for the Windows side of this: bug 237079
Comment 6 Angelo 2005-03-02 05:12:22 PST
Created attachment 176031 [details]
Open with dialog

This is the standard Open with dialog on Gnome, maybe this one should be used
Comment 7 Angelo 2005-03-02 05:51:38 PST
This one should be moved to OS Integration (or at least File Handling) component
and should have enhancement severity
Comment 8 Akkana Peck 2005-04-14 11:40:48 PDT
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 2005-07-13 07:43:38 PDT
"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 10 Carsten Book [:Tomcat] 2007-06-04 00:58:20 PDT
*** Bug 346870 has been marked as a duplicate of this bug. ***
Comment 11 Corey Woodworth 2007-12-03 02:49:44 PST
Amen. I'm really hoping this gets fixed before 3.0 is released.
Comment 12 [:Aleksej] 2008-04-21 23:36:47 PDT
A related (but different, though some bugs like it have been duped here) bug: bug 370380.
Comment 13 Edd 2008-11-02 06:09:37 PST
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 2009-03-22 10:14:18 PDT
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 2009-06-16 01:55:18 PDT
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 2009-09-26 22:37:58 PDT
Is this a dupe of Bug 397700?
Comment 17 Akkana Peck 2009-09-26 22:53:36 PDT
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 2014-05-06 01:42:08 PDT
This issue extends beyond opening files to, for example, selecting an application to view RSS feeds.

Note You need to log in before you can comment on or make changes to this bug.