Closed Bug 370380 Opened 16 years ago Closed 14 years ago
Cannot easily select alternative helper applications in "Open With" dialog
User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:126.96.36.199) Gecko/20070213 Fedora/1.0.7-0.6.0.1.fc5 SeaMonkey/1.0.7 Build Identifier: Fedora/firefox-188.8.131.52-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.
Related: bug 234704.
martin, does this still apply to trunk?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Some bugs like this one have also been marked duplicate of bug 259594.
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)
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.
This is also tracked in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/18995
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.
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,
Looks like a good solution. This bug isn't assigned to anyone, any takers?
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.
See comment #8
Depends on: 397700
Priority: -- → P2
Target Milestone: --- → Firefox 3.6a1
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 397700
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?
(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 on attachment 369235 [details] [diff] [review] Use default linux system integration Clearing review request from a duplicate bug
You need to log in before you can comment on or make changes to this bug.