541713 - Download Manager no longer recognize MIME types under Linux, making impossible to open downloaded files

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Tom Maneiro]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); es-AR; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); es-AR; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6

After updating from Firefox 3.5.7 to the newest and greatest 3.6, file associations stopped working on my Fedora Core 6 system. Now, the Download Manger asks me to pick an application to open "file" links for every file, no matter the MIME type. Also happens with "Open Containing Folder". This also means that downloaded files will have no matching filetype icons.

Although FC6 is ancient, FF3.5.7 worked fine with no issues.

Reproducible: Always

Steps to Reproduce:
1. Download any file that requires an external app for open it under Linux (let's say, a ZIP file), select "Save it to disk"
2. Wait the download to complete
3. Double-click the file on the Download Manager (or right-click the file, and select "Open Containing Folder")
Actual Results:  
The "Start Application" window pops up, asking me to select an application for opening the file/folder

Expected Results:  
The file should open with the default application specified on the system. For example, GNOME users will get their .ZIP files loaded on file-roller. Folders should open with Nautilus, or something like that.

Deleting mimeTypes.rdf has no effect. Even worse, specifying the app may not work, depending on how the app deals with file/URL paths (for example, GNOME' File-roller says that the file does not exist (!), but KDE apps have no problem opening the files. Looks like FF is sending a file:// URL as the file path - KDE apps that use Kioslaves have no problems for dealing with such paths, but GNOME apps do (file-roller does not like "file-roller file:///path/to/file.zip")

Comment 1

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 2

[Tyler Downer [He/Him]]

This bug has had the CLOSEME tag for several weeks and the date in the tag is far gone. If the reporter can still see this issue, Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). Then please remove the closeme tag in the whiteboard, mark the bug against the proper version and comment on the bug.