Bug 227374

Summary: Cannot easily select alternative helper applications
Product: [Fedora] Fedora Reporter: Philip Spencer <pspencer>
Component: firefoxAssignee: Christopher Aillon <caillon>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 6CC: mcepl, stransky, wtogami
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-02 12:45:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch allowing firefox to list all registerd apps for a mime type none

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

1.5.0.9-2.fc6

How reproducible:

Always

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
Hello,

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

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=370380

Comment 6 Martin Stransky 2008-01-03 14:22:51 UTC
Reporter, can you please add yourself to the upstream bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=370380)?