firefox choose helper application dialog is useless

Bug #111818 reported by randomwalker
60
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Medium
firefox-3.0 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: firefox-gnome-support

There are a number of bugs against firefox's choose-helper-application dialog such as it doesn't work in kde, doesn't let you find / , etc. This bug encompasses all those bugs.

The choose-helper-application dialog is fundamentally broken in a way that's not fixable. File type association and the required user interface for it is a tricky process that is quite hard to get right. There is no way the browser can expect to do this in a platform independent way. The dialog is clearly focused on being easy for Windows users, but on Linux it's a joke. It's not in any circumstance acceptable to ask the user to choose the exact path to the program. The filesystem layout makes that hellish, and it's just the way linux is.

The only sane choice is to invoke gnome's (or kde's) open-with dialog. I don't know if this is something that can be easily added to a browser given that it lives in a sandbox and all. But as far I can see, any other choice, especially the current one, is completely insane.

Revision history for this message
In , Brendthess (brendthess) wrote :

Created attachment 160420
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.

Revision history for this message
In , Brendthess (brendthess) wrote :

Created attachment 160421
Result window for DL manager

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

Revision history for this message
In , Scottappleby (scottappleby) wrote :

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.

Revision history for this message
In , Scottappleby (scottappleby) wrote :

Created attachment 163237
windows "open with" dialog

Revision history for this message
In , Moz-jomel (moz-jomel) wrote :

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

Revision history for this message
In , Ang3l0-katamail (ang3l0-katamail) wrote :

Created attachment 176031
Open with dialog

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

Revision history for this message
In , Ang3l0-katamail (ang3l0-katamail) wrote :

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

Revision history for this message
In , Akkana Peck (akkzilla) wrote :

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

Revision history for this message
In , Garym-canada (garym-canada) wrote :

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

Revision history for this message
randomwalker (randomwalker) wrote :

Binary package hint: firefox-gnome-support

There are a number of bugs against firefox's choose-helper-application dialog such as it doesn't work in kde, doesn't let you find / , etc. This bug encompasses all those bugs.

The choose-helper-application dialog is fundamentally broken in a way that's not fixable. File type association and the required user interface for it is a tricky process that is quite hard to get right. There is no way the browser can expect to do this in a platform independent way. The dialog is clearly focused on being easy for Windows users, but on Linux it's a joke. It's not in any circumstance acceptable to ask the user to choose the exact path to the program. The filesystem layout makes that hellish, and it's just the way linux is.

The only sane choice is to invoke gnome's (or kde's) open-with dialog. I don't know if this is something that can be easily added to a browser given that it lives in a sandbox and all. But as far I can see, any other choice, especially the current one, is completely insane.

Revision history for this message
Chriki™ (chrikitm) wrote :

Thanks for your bug report. I can confirm that the current situation is not satisfactory; there's already an appropriate upstream bug report concerning this problem in Mozilla's bug tracker (see above).

Changed in firefox:
status: Unconfirmed → Confirmed
Changed in firefox:
status: Unknown → Unconfirmed
Changed in firefox:
assignee: nobody → mozilla-bugs
Revision history for this message
Alexander Sack (asac) wrote :

randomwalker, can you please rephrase the point you are trying to make in just a few words?

Revision history for this message
Alexander Sack (asac) wrote :

this bug report needs a decent description and summary before we can set this to confirmed.

Changed in firefox:
status: Confirmed → Needs Info
Revision history for this message
In , Cbook (cbook) wrote :

*** Bug 346870 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: Unconfirmed → Rejected
Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Corey Woodworth (coreywoodworth) wrote :

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

Revision history for this message
hotani (hotani) wrote :

Maybe this will clarify: the "open with" process in Firefox is unusable under linux.

To Reproduce: Click on any file that the browser does not handle internally. In my case that may be a CSV file. From the download dialog, I have the option to download it, or "open with" another application. If the app I want to open it with is not listed, I have to browse for it. For many new or even moderately experienced Linux users, this means, "Game Over." There needs to be an 'app browser' a la XFCE which lists "suggested applications," then "all applications."

Same thing in Preferences->Applications. By the content type there is an "Action" drop-down. If the desired app is not in that list, then the user is forced into the bowl-o-spaghetti that is the linux filesystem and application hiding^W organization scheme.

Revision history for this message
In , Aleksej (aleksejrs) wrote :

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

Revision history for this message
In , Eddbarrett (eddbarrett) wrote :

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

Revision history for this message
John Vivirito (gnomefreak) wrote :

Updated for 3.0

Changed in firefox (Ubuntu):
assignee: mozilla-bugs → nobody
Changed in firefox-3.0 (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
In , John Vivirito (gnomefreak) wrote :

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

Revision history for this message
John Vivirito (gnomefreak) wrote :

Commented on upstream to find out status of bug report.

Revision history for this message
In , Thomas Ibbotson (thomas-ibbotson) wrote :

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.

Revision history for this message
In , Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote :

Is this a dupe of Bug 397700?

Revision history for this message
In , Akkana Peck (akkzilla) wrote :

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.

Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.