From bug 293804 comment 8: > 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. From bug 293804 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. 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. I looked here; and I think in the clause beginning at: http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2714 there COULD be, after the call to GetMIMEInfoForExtensionFromDS(), an explicit line: |*_retval->SetAlwaysAskBeforeHandling(true);| This would *force* the case where the handler (as located in mimeTypes) was located by extension rather than MIME type to prompt. However, it doesn't "allow the app ... [to] make an informed decision." Is an "informed decision" really necessary? What's the scenario where we always want to proceed with the action looked up via the extension?

The scenario is some Gecko-based app that wants to do that. Basically, we need to give the embeddor control over the behavior here somehow. I hesitate to suggest a pref.... Can Show() on mDialog just not put up a dialog if it doesn't want to? If so, perhaps we can just indicate the reason we're asking (via the mReason stuff)?

There are actually two problems (all Mac OS X related). The first: When the user opens an attachment, TB checks the mimetype.rdf file if there is a rule for the attached file's extension. If this is not present, the user is asked to select a program. If he does, then that link will be saved afterwards to mimetype.rdf. It will always do this (Mac specific), even if 'Do this always' wasn't checked. This means that once you open a file with the wrong application once, it will thereafter try to use that application indefinitely. You have to delete the rule from the settings to be able to reset it. The second: When the user opens an attachment, TB checks the mimetype.rdf file if there is a rule for the attached file's extension. If one is present then the attachment will be instantly sent to that application. The bug is that TB doesn't care in any way about the MIME type of the file, just its extension (this behavior has been described in Bug: 293804). Imagine the horror with files that have no extension (which is not that uncommon on Mac systems, especially those before Mac OS X. The third: The second is that TB uses the data in the mimetype.rdf file to generate MIME types for outgoing mail. It disregards the MIME type when opening an attachment, but it does generate them when sending one. And as is generates this based on the attached file's extension, this suffers from the exact same flaw as the previous problem I described. Worse however is that the recipient (whose mail app will of course check the MIME type) is unable to open it correctly, because it tells the recipient the file should be opened with 'app X', whereas the sender and recipient expected an 'app Y'-file. There is no workaround for when you are working with files that have similar extensions (or none) that open in different applications (and have different MIME types). For the first problem the workaround would be to open valid files, upon a new installation and check the 'Do this always'-checkbox. After that you can save the mimetypes.rdf file and distribute it to other new installations or existing users. It would be nice however if this could be solved permanently, as this is preventing our organization from being able to adopt TB network-wide.