Bug 227374 - Cannot easily select alternative helper applications
Summary: Cannot easily select alternative helper applications
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-05 18:05 UTC by Philip Spencer
Modified: 2018-04-11 10:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-02 12:45:34 UTC
Type: ---

Attachments (Terms of Use)
Patch allowing firefox to list all registerd apps for a mime type (33.30 KB, patch)
2007-02-05 18:05 UTC, Philip Spencer
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Mozilla Foundation 370380 0 None None None Never

Description Philip Spencer 2007-02-05 18:05:25 UTC
Description of problem:

If someone right-clicks a file on, say, their GNOME desktop, they see an "Open
With" menu that shows all the applications registered to handle files of that
MIME type. However, if they click on that same file on a web site with firefox,
they only get a single choice of application with which to handle it, plus the
option of manually browsing to a path. They no longer see the same list of
relevant applications.

Example scenario where this may pose a usability problem:

User is accustomed to opening PDF files with "Document Viewer" (evince). Then
Adobe Reader gets installed on the system, replacing evince as the default app
for pdf files. The user is more familiar with evince and prefers to keep using
it. For local files this is not a serious problem: they right-click on the file
and choose "Document Viewer" from the "Open With" menu.

However, for pdf files on the web, the option of opening the file with Document
Viewer has, from the user's perspective, completely been taken away from them.
The only items on the "Open With" menu are "Adobe Reader" and manually browsing
to find an application. If they are a novice user, they may not know that
"Document Viewer" = "/usr/bin/evince" and will not be able to find their old
preferred application.

It would be much better if firefox's "open with" menu matched the "open with"
menu a user sees for local files.

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. Select a link to a downloadable file.
2. Observe the list of applications presented in the "How do you want to handle
this file?" dialog.
3. Compare with the list of applications in the "Open With" menu if that file is
stored locally and is right-clicked-on inside the GNOME file browser.
Actual results:
Firefox only shows the default application, not any other applications
registered for that MIME type. The GNOME file browser's "Open With" menu shows
them all.

Expected results:
It would be nice if firefox showed them all as options.

Additional info:
I have created a patch which implements this suggested enhancement. However, I
have never even looked at the firefox/mozilla source code before now, so I do
not know enough about the firefox internals to create a patch that is as
efficient and fully featured as I would like.

Also, I'm not 100% confident that my memory/pointer handling is all correct (the
firefox code convention learning curve is pretty steep!) I think I've avoided
any inappropriate free's but there may be some memory leaks.

However, the patch should be a starting point for someone more familiar with
firefox internals to look over and modify.

Basically, what I've done is as follows. Since I don't know enough to be able to
change the format or structure of any data files (such as mimeTypes.rdf), I've
simply altered the code so that, when useSystemDefault is selected, it doesn't
just use "the" default application -- rather, it looks at the
preferredApplicationHandler field and if that matches one of the other apps
registered for the mime type, that app is used instead. Then, the dialogs where
the user is asked to select the app are augmented with the addition of these
other apps, and if the user selects one of them the code will put the app into
preferredApplicationHandler but also set useSystemDefault. If the user selects
the real default application the code will clear preferredApplicationHandler
along with setting useSystemDefault.

I've added one attribute and two methods to the nsIMIMEInfo interface: an
attribute holding the number of alternative system applications, and methods for
getting the description and path of these alternative apps.

I realize a patch like this really belongs upstream, but I see that most of the
linux-compatibility work on firefox is actually being done by RedHat so I
figured here might be the best place to post it after all.

I hope someone more familiar with firefox internals than I am can take this
patch and rework it into something efficient and correct and fully conforming to
firefox code conventions.

Comment 1 Philip Spencer 2007-02-05 18:05:25 UTC
Created attachment 147382 [details]
Patch allowing firefox to list all registerd apps for a mime type

Comment 2 Martin Stransky 2007-02-14 13:13:41 UTC

all code changes have to be reviewed by mozilla upstream, so we need to report
it to the upstream anyway. And I think it's a good idea, I'm missing this
feature in firefox/seamonkey so please go ahead and report it, eventually attach
link to upstream BZ # here...

Comment 3 Matěj Cepl 2007-02-14 13:36:41 UTC
To be slightly more precise on the need of the file this bug upstream. Please
file a bug report in the Mozilla bugzilla located at http://bugzilla.mozilla.org
in the "Firefox" product, "File Handling" component.

Once you've filed your bug report upstream, if you paste the new bug URL here,
Red Hat will continue to track the issue in the centralized X.Org bug tracker,
and will review any bug fixes that become available for consideration in future

Setting status to "NEEDINFO", and awaiting upstream bug report URL for tracking.

Thanks in advance.

Comment 4 Matěj Cepl 2007-02-14 13:46:42 UTC
Of course, I meant "Mozilla bug tracker". :-)

Comment 5 Martin Stransky 2007-02-14 14:16:19 UTC
Never mind, the upstream bug was filled:


Comment 6 Martin Stransky 2008-01-03 14:22:51 UTC
Reporter, can you please add yourself to the upstream bug

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