User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 I received a message with a winmail.dat attachment which was properly tagged with a MIME type of application/ms-tnef. When I tried to open the attachment, the pop-up window said the file was an MPEG video and offered to use a video player to view the file. This happened because on Fedora Core 3 (which I use), the MIME type of files with .dat extension is video/mpeg (according to the file /usr/share/mime-info/gnome-vfs.mime, part of the gnome-mime-data-2.4.1-5 package). Thunderbird should not use the file extension of attachments to figure out what to do. It should use the MIME type. That's what it is for. (This is one of the major problems in Outlook, there is no need to repeat blunders.) Reproducible: Always Steps to Reproduce: 1.Try to open a winmail.dat attachment with MIME type application/ms-tnef 2. 3. Actual Results: pop-up asking what to do with an MPEG video. Expected Results: pop-up asking what to do with an application/ms-tnef.

Interesting -- I had thought this was a Windows-only problem. I don't know whether Linux (or any of its window managers) supports a MIME registry; I'm surprised to learn, from this bug report, that there is a file-extension registry, as I thought such things were Not the Linux Way. Mozilla maintains its own listing of supported MIME types, in mimeTypes.rdf, and associates extensions with them; but those extensions, and the extensions listed in the system registry, are used only if no entry can be found for the MIME type. The extensions listed in mimeTypes.rdf can be seen (in Thunderbird) under the Options dialog for Attachments. Note that this dialog has been improved somewhat for pre-1.1 builds; in particular, if you select Change Action, the MIME type associated with the extension is displayed. Under Windows, when I open an attachment: - If the MIME type is listed in mimeTypes.rdf, those settings are what's used to handle the file -- regardless of the file extension. - If the MIME type is not listed, but it *is* registered with the system, then the system registry settings are used to determine what the likely action to take is, but that action is not automatically taken; instead, the user is presented with a dialog showing the presumed action, but allowing an alternate action to be selected. - If the MIME type is neither listed or registered, then TB looks up actions associated with the extension -- again, first in mimeTypes.rdf, then in the system registry. If a match is found, then again, the user is presented with the dialog presuming the match was correct, but allowing an alternate action. This last, I believe, is the case you have encountered (altho you didn't state whether TB has its own entry for .DAT associated with video/mpeg); and if you've followed my logic, I think you'll see that this is the best way to provide a hint to the user as to which application should apply. By the way, application/ms-tnef is not supported: see bug 77811. It would be useful if you could verify this behavior holds under Linux, with the Gnome association list being referred to similarly to the Windows registry. If the behavior described above does apply, you should mark this bug: Resolved | Invalid See also bug 277046.

A little more information: The action-select dialog also allows the user to check a box indicating that the selected action should be the default. This means, make it the default action for this MIME type (note that Thunderbird does not display the MIME type in this dialog, while Mozilla does). The major drawback is that it also forces an association of the extension to the MIME type in mimeTypes.rdf, thus de- associating it from the previous MIME type. In the Mozilla suite, that last point is a nuisance; however, it's possible to go into the preferences and re-assign the extension to the original MIME type -- because Seamonkey presents the preferences *by* MIME type. Among other advantages, it allows configuring MIME types in the list with zero, one or more than one extension. Thunderbird presents the data by extension, presumably for the benefit of the Windows users who don't know nuthin' 'bout no MIME types; there is no way to edit the extension-to-MIME association list. This makes the problem reported here more inconvenient. (See also bug 244618.) However, it's not that important because if another message arrives with a .DAT file listed as video/mpeg, it will be treated as video/mpeg. Workarounds for this last issue are: 1) edit mimeTypes.rdf by hand; OR 2) Install Seamonkey, edit mimeTypes.rdf by creating appropriate entries in Preferences|Navigator|Helper Applications, and then copy the resulting .rdf file to the Thunderbird profile; OR 3) Open the attachment with the undesired extension, select the desired action (probably Save to Disk, for application/ms-tnef), and select the "Always use this action..." checkbox. Then, to reassociate .DAT with video/mpeg, DELETE the video/mpeg entry from Options|Attachments, and then re-open a video/mpeg attachment with a .DAT extension. The presumed action should be correct (gotten from the Gnome registry), so again select "Always use...". mimeTypes.rdf should now contain information for default handling of application/ms-tnef (with no associated file extension) and for video/mpeg (with the .DAT extension associated).

So, do I understand correctly that what happens is this: application/ms-tnef is looked up in various places but not found, then dat extension is looked up and found in the gnome registry, then the MIME type that was found there is used to prompt the user. If this is the case, then there is a bug and this should not be marked Resolved | Invalid. It's ok if the MIME type can't be found, but it's not ok to then assume that the MIME type was incorrect and use whatever was found in some registry. The solution is not adding something for application/ms-tnef, the solution is fixing the dialog and associated code. As to your question in the first response, it looks like your analysis could be correct. I believe I did experiment with changing the gnome registry when I first filed this report. All the mimeTypes.rdf files I could find (2 each under /usr/lib/thunderbird-1.0.2 and in my profile directory) are essentially empty.

(In reply to comment #3) > So, do I understand correctly that what happens is this: > application/ms-tnef is looked up in various places but not found, > then dat extension is looked up and found in the gnome registry, > then the MIME type that was found there is used to prompt the user. > > If this is the case, then there is a bug and this should not be marked > Resolved | Invalid. OK. I guess you mean that Thunderbird shouldn't display the prompt as "file.dat... which is a: MS Video file" but instead be more precise; I agree, and I'll update this bug's summary and severity accordingly. However, see bug 276099. But if you're saying the bug is that Thunderbird shouldn't consider the extension at all -- forcing the user, in many instances, to have to hunt around for the application that the system already has registered -- then I disagree. The reality of the situation is that extensions most often are unique to a particular MIME type, and it is quite reasonable to present that application as a suggestion.

Incidentally: on testing, workaround #3 from comment 2 doesn't appear to work; in fact, I think there's another bug there. If Thunderbird has a default action listed in mimeTypes.rdf -- say, video/mpeg, assoc'd with .dat, automatically opened -- and you then click on an attachment with the same extension, but a different, unlisted MIME type: then TB opens the attachment using the video/mpeg action; it never prompts for what to do with the new MIME type. This seems wrong to me. Note that Firefox (Deer Park) can handle multiple MIME types associated with a single extension (xref bug 283820), and TB should be able to support that as well. While I was testing for that bug, I encountered (or I'm pretty sure I encountered) a case where Firefox did the same thing: assumed the action for a download according to the extension, rather than the MIME type; but I wasn't able to reproduce it after restarting the program.

Here's my suggestion: Expected results: If the attachment MIME type is not registered in mimeTypes.rdf, then display the prompt *dynamically* depending on whether the MIME type or the extension is known from the system registry. * MIME type known to OS (same as current behavior): You have chosen to open: file.ext which has a known type of: WhateverSoft Document (MIME type: application/whatever) [presents <Open In WhateverSoft> as suggested action] * MIME type unknown to OS, but extension is registered to access a program (either directly or via a different registered MIME type): You have chosen to open: file.ext which has an unknown MIME type of: application/whatever The ".ext" extension is known to be used for ExtSoft Document files [presents <Open In ExtSoft> as suggested action] * Both MIME type and extension unknown to OS: You have chosen to open: file.ext which has an unknown MIME type of: application/whatever The ".ext" extension is also unknown. [presents <Save to Disk> as suggested default] The second and third cases are more precise; the second case does not assume that the same extension means the same file types.

I've been investigating current behavior of MIME problems due to the possibly related problem at bug 353815 / bug 364594. Some of my analysis above seems flawed. I don't remember, now, which extensions & types I might have been using for testing -- possibly .DAT and video/mpeg, as described in the original bug. I'm currently testing with TB 1.5; 2b1 and 3a1 builds seem to be behaving basically the same, as far as this bug is concerned. My testcase is a mimeTypes.rdf with a plain old |application/msword| association to .DOC, defined for "Open in Word"; and a message with a Word attachment "x.doc" that I've hacked to give a MIME type of application/cdf. (In reply to comment #1) > Mozilla maintains its own listing of supported MIME types, in mimeTypes.rdf, > and associates extensions with them; but those extensions, and the extensions > listed in the system registry, are used only if no entry can be found for the > MIME type. > > Under Windows, when I open an attachment: > > - If the MIME type is listed in mimeTypes.rdf, those settings are what's > used to handle the file -- regardless of the file extension. This is true. > - If the MIME type is not listed, but it *is* registered with the system, > then the system registry settings are used to determine what the likely > action to take is, but that action is not automatically taken; instead, the > user is presented with a dialog showing the presumed action, but allowing > an alternate action to be selected. This no longer happens. > - If the MIME type is neither listed or registered, then TB looks up actions > associated with the extension -- again, first in mimeTypes.rdf, then in the > system registry. If a match is found, then again, the user is presented with > the dialog presuming the match was correct, but allowing an alternate action. This no longer happens either, exactly. Instead, I'm seeing both of the above cases immediately using the extension's default action, without prompting, and also without creating a new entry in mimeTypes.rdf. (That is, opening an attachment now behaves just like clicking the link in bug 277046.) (In reply to comment #5) > Note that Firefox (Deer Park) can handle multiple MIME types associated with > a single extension (xref bug 283820), and TB should be able to support that > as well. And in fact, once those multiple MIME types are in place with associations to a single extension, there are multiple entries listed for the extension; but I'm not sure how the program selects the action taken on an unknown MIME type of the same extension. I have a (corrected) mimeTypes.rdf from bug 364594, which has three entries for .DOC -- application/msword using "Open in Word," and two other ersatz ones with "Save to Disk"). But if I try to open the .DOC file with the application/cdf MIME type (and don't have an application/cdf entry in mimeTypes.rdf), it always opens in Word, whether that entry is first or second in the list.

This extension-vs-MIME-type behavior is identical to Firefox (2.0) and Seamonkey (1.5) in the way they handle downloaded files: If the MIME type is not registered in mimeTypes.rdf but the extension is known to be associated with a different MIME type, then the action for that type will be taken. (This is unrelated to handling application/octet-stream, which is known to be generic. Also xref Hixie's bug 229688.) This seems broken to me; for a reason why, see comment 0. I don't know how this behavior was ever allowed to advance to this point. I still think comment 6 would be a good approach; if the current behavior really is by design, please change this to an RFE for a better approach. And if anyone knows the correct component to put this in, please reassign it.

So the way it _used_ to work is that you'd request a MIME info for a type and extension combination (the latter because so much stuff was application/octet-stream but had a useful extension). The MIME service would do what it could -- give you back a MIME info based on type, and if the type is completely unknown to everyone fall back on looking up based on the extension -- and returning a MIME info that has a _different_ type from the original, so the callee can detect that this happened. Then we changed things to reset to the original type so any decisions got remembered with the original type (effectively adding a new extension-to-type mapping if the user asked us to). Now if you actually load such a beastie in the browser (broadly interpreted here to mean a <browser> chrome element), the assumption is it's better to offer a GIF viewer for an application/octet-stream body with a .gif filename than to offer nothing at all. Now one could argue that perhaps the extension should only be used for application/octet-stream. I would be willing to buy that, I think, with a _lot_ of testing. This code is kind of prone to creating usability nightmares when changes like this happen. :( One could also argue that the UI should always prompt (never do the action automatically) when the action was looked up by extension. Again, I would be happy to add back end code to communicate this information to the UI so the app author can make an informed decision. My $0.02.

My comment 8 should have made clear: the unknown-MIME + known-extension = automatic-open issue only occurs when the extension is known in mimeTypes.rdf. If it's been identified from the system registry, the regular Opening prompt is provided, allowing the user to register the MIME type (and extension) in mimeTypes.rdf, along with the action of opening in the program registered in the system. (In reply to comment #9) > Now one could argue that perhaps the extension should only be used for > application/octet-stream. I don't think that's quite what's needed here. If the MIME type is unrecognized but the extension is known to have a handler (from either mimeTypes or the OS), we should present that handler so the user doesn't have to search for it, in case the MIME type is essentially the same (a .JPG with image/jpeg2000 may well be compatible with the image/jpeg handler). The main difference between this and application/octet-stream is, I might want to save a default action for the type. > One could also argue that the UI should always prompt (never do the action > automatically) when the action was looked up by extension. I think that's right. That would help overcome the problem described in comment 8, and it would be necessary to implement the proposal in comment 6. > Again, I would be happy to add back end code to communicate this information > to the UI so the app author can make an informed decision. Boris, does that same back end code do the lookup in the OS's registry to find the system's default handler if the extension is unknown? I guess what would make the most sense to me is that the information returned for an extension-known-to-mimeTypes be the same as for an extension-known-to-the-OS. Even if the extension is in the mimeTypes has an action of "save" I would like to see the default system handler presented in the prompt for the new MIME type.

> a .JPG with image/jpeg2000 may well be compatible with the image/jpeg handler Ah, right. I knew there was a reason we did things that way. It's been a long time since I've seriously thought about this code. ;) > Boris, does that same back end code do the lookup in the OS's registry to find > the system's default handler if the extension is unknown? Yeah. See nsExternalHelperAppService::GetFromTypeAndExtension and the various per-platform GetMIMEInfoFromOS methods. The Linux impl of GetMIMEInfoFromOS is what would know whether the data it got it got for the type or the extension.... And then GetFromTypeAndExtension does the looking in mimeTypes.rdf and all that (GetMIMEInfoForMimeTypeFromDS and GetMIMEInfoForExtensionFromDS calls).

(In reply to comment #9) > One could also argue that the UI should always prompt (never do the action > automatically) when the action was looked up by extension. Assuming this is how we should proceed... (In reply to comment #11) > See nsExternalHelperAppService::GetFromTypeAndExtension and the various > per-platform GetMIMEInfoFromOS methods I looked here; and I think in the clause beginning at: http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2714 there should be, after the call to GetMIMEInfoForExtensionFromDS(), an explicit line: |*_retval->SetAlwaysAskBeforeHandling(true);|

(In reply to comment #12) > there should be, after the call to GetMIMEInfoForExtensionFromDS(), an > explicit line: Well, maybe not. Anyway, that's orthogonal to this bug; I've opened bug 366879 for this issue.