370380 - Cannot easily select alternative helper applications in "Open With" dialog

Status: RESOLVED DUPLICATE of bug 397700

(Firefox :: File Handling, enhancement, P2)

Description

[Martin Stránský [:stransky] (ni? me)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.8.0.9) Gecko/20070213 Fedora/1.0.7-0.6.0.1.fc5 SeaMonkey/1.0.7
Build Identifier: Fedora/firefox-1.5.0.9-2.fc6

Note: this is a dupe of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227374

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.



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.

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

[Martin Stránský [:stransky] (ni? me)]

Attachment: proposed patch (created by pspencer 'at' fields utoronto ca)

Comment 3

[[:Aleksej]]

Related: bug 234704.

Comment 4

[Alexander Sack]

martin, does this still apply to trunk?

Comment 6

[[:Aleksej]]

Some bugs like this one have also been marked duplicate of bug 259594.

Comment 8

[Mike Hommey [:glandium]]

Looks like the patch should be reworked to use the result of bug #348808 (only for windows, now, but bug #397700 is the linux version ; I guess there is a mac one, too)

Comment 9

[[e-mail]]

Worse yet:

-- The list of content types can't be modified, even to add something identified only by file extension.  I just ran into this when trying to get a .ssa file.  Firefox tried to open it and couldn't (not surprising).  There's no way to add "file with extension ssa" to the content type list, and I have no idea whatsoever whether Firefox thinks it has a mime type or is just treating it as unknown.
-- On that subject, there's no entry for "unknown content type" (at least on my machine).  Want to tell Firefox to save all files with an unknown content type?  Forget it.
-- There's no way to tell Firefox whether to determine content type by extension first or by Mime type sent by the server first.  I recently tried to open a PDF file whose content type Firefox seemed to think was BIN.  There was no way to tell Firefox that the .PDF in the filename takes precedence over the bogus Mime type sent by the server.
-- There's usually no option "open in browser".  I want to tell Firefox to open text files in Firefox.  Can't do that.

Comment 10

[X x]

This is also tracked in Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/18995

Comment 12

[Matthew Craig]

Bug 483414 - take a look at what other "Open With Application" programs do, for example, the command line 'which' application and, even better, the 'Gnome-Do' application.

Linux does not list all applications in a single file directory, like some other operating systems.

Comment 13

[Michel Loiseleur]

Attachment: Use default linux system integration

Hi *,

   We encountered this problem during an important linux migration (~ 1000 linux desktop based on kubuntu). 
   With Firefox 3, it has became a really serious problem : we cannot train our users to open /usr/bin and select the good associated program for each file type. There's quite a lot of issues about this :
https://bugzilla.mozilla.org/show_bug.cgi?id=369431
https://bugzilla.mozilla.org/show_bug.cgi?id=327323
https://bugzilla.mozilla.org/show_bug.cgi?id=250914
https://bugzilla.mozilla.org/show_bug.cgi?id=315255
https://bugzilla.mozilla.org/show_bug.cgi?id=393502
https://bugzilla.mozilla.org/show_bug.cgi?id=409558
https://bugzilla.mozilla.org/show_bug.cgi?id=218257
https://bugzilla.mozilla.org/show_bug.cgi?id=428658  


   So we tried different path (and patches) and we found one which looks promising, based on xdg-open. The reasoning behind is simple : Firefox is NOT an operating system, so there should not be any file association in it.
   This small patch removes the problem and its origin : the "open with" concept. 

   Windows, Mac OS or Linux Desktop environment (GNOME, XFCE, KDE, etc) has all already a file association system, with a preferred application already set. The patch submitted here is a step towards this direction, but works only for Linux. 
   Using xdg-open, every single file encountered on internet is correctly openend with the program already setted in the OS preferences. It seems also a path to a usability improvement : changing "open with" label with something like "open file" and it removes a question for Firefox users.
   
   I have seen some security problems encountered on Slackware which also used this approach, but for me, the security problem was in xdg-open not in the link between Firefox and xdg-open.

   Would you please tell me what do you think of the patch and the way it takes for solving this issue ?

Regards,

Comment 14

[X x]

Looks like a good solution.

This bug isn't assigned to anyone, any takers?

Comment 15

[Robert Kaiser]

I'm no module owner so nobody who can decide, but as long as we have things like a helper application pref pane, whatever is in there needs to be reflected in the open dialog somehow. Additionally, I don't always want to open files of the same type with the same application, even more so when they are sent with wrong types or I know some type is actually readable as plain text and I want to open with kwrite or some other text editor to just see/check the contents.
Going through xdg is a good idea, but not offering other options, including some app selector is a serious bug IMHO.

Comment 16

[Mike Hommey [:glandium]]

See comment #8

Comment 18

[Matthew Craig]

Jim Mathies, 
Why was this earlier bug report marked as a duplicate of a later bug report?  Should it not be the other way around?

Comment 19

[Jim Mathies [:jimm]]

(In reply to comment #18)
> Jim Mathies, 
> Why was this earlier bug report marked as a duplicate of a later bug report? 
> Should it not be the other way around?

Seemed like bug 397700 had more pertinent information on how to implement the feature and matched the requirement in terms of title and discussion. You're welcome to swap them out, I just wanted to consolidate the linux requirement into a single bug.

Comment 20

[Shawn Wilsher :sdwilsh]

Comment on attachment 369235 [details] [diff] [review]
Use default linux system integration

Clearing review request from a duplicate bug