From discussion in bug 122815: ------- Additional Comment #13 From Jean-Francois Ducarroz 2002-02-05 12:09 ------- >With this patch, do we ignore x-mac-type="54455854" x-mac-creator="4D4F5353" in >the MIME info for the attachment, defaulting to what IC tells us? Or do we go >first with this type/creator, and then fall back on IC iof it's not present? No, I am not using the attachment signature because mime does not provide it to the frant-end. This is a have discovered while working on this patch fo which I have decided to not do anything whith that (at least for now) because of the following reason: If user A send to user B a JPEG image created by a specific program. User B does not have that specific program but use another one to display image. If we use the application type/creator from the sender, we will have a file with no icon (but the user should stil be able to use it in that particular case but that might be not true in every case). However, using only the content-type, we are able to setup the file for the user B image application. If you really think it's an issue, I'll file another bug for that. ------- Additional Comment #14 From Simon Fraser 2002-02-05 12:18 ------- This was an issue in the 4.x days too. The question is do you go with the sender's type/creator (which are known to be correct for the file), or do you rely on mime type/file extension and IC, which may assign an incorrect type/ creator to the file? In addition, what do you use when displaying the attachment icon in the message (if/when we use native icons there). It annoys me that 4.x shows CodeWarrior file attachments in the message window, but when I save them I get BBEdit files. This seems wrong. Also, bear in minde that on Mac OS X, there is no UI to allow the user to edit their IC-specified mime/extension mappings. Maybe we need input from UE folks on the type/creator problem.

Adding Marlon and Andrew since they know more about Mac than me.

The type and creator code should always take precedence over the MIME type. MIME should only be used to handle files while within Mozilla. Once a file leaves Mozilla due to being saved, any type/creator information it has should be saved with it.

Let me give an example of why this is a good idea. I create three sample documents in Microsoft Word 98. I save one as Word 98, one as Word 6.0/95, and one as Word 5.1. I send three test e-mails in Mozilla with one of the samples attached. Mozilla sends the attachments with the three different type codes included (W8BN/5738424E, W6BN/5736424E, and WDBN/5744424E), and the same creator code (MSWD/4D535744). Because of the configuration of my MIME types, samples 1 and 3 get a MIME type of application/msword, while Sample 2 gets application/octet-stream. Also because of my configuration, Samples 1 and 3 are saved as WDBN/MSWD, while Sample 2 is saved as BINA/hDmp. Not exactly a useful state of affairs. The receiving user potentially not having an application with the matching creator code isn't a good enough reason to ignore the type and creator codes. It's what File Exchange exists for. Mozilla's job should simply be to save the Mac file as faithfully to the original as it can.

Is this still relevant for Mac OS X ? Apple screwed their own type/creator support in favor of the file extension. As long as the user sends us a *.jpg or *.jpeg file, we'll open it in the right applciation, even if the type/creator is missing. And users will have to use that file extension anyway, otherwise they're screwed on Windooze. On the other hand, I still think it's useful to set the type/creator if we they have been send as MIME-info. We'll be smarter than the OS in that case. And the OS will still helps us to open the file in another application, if the original isn't present. So, I agree with Greg on this one. Should we move this to Mac OS X ?

Over to OS X.

In Mac OS X, when a document is opened from the disk, the file extension should take precedence over the type and creator code. See: http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_8.html#//apple_ref/doc/uid/TP30000999-CH202-DontLinkElementID_8 I would guess that the same should be true when opening an attachment. What does Mail.app do? In Mac OS (In reply to comment #4) > Is this still relevant for Mac OS X ? Apple screwed their own type/creator > support in favor of the file extension. As long as the user sends us a *.jpg or > *.jpeg file, we'll open it in the right applciation, even if the type/creator is > missing. And users will have to use that file extension anyway, otherwise > they're screwed on Windooze. > > On the other hand, I still think it's useful to set the type/creator if we they > have been send as MIME-info. We'll be smarter than the OS in that case. And the > OS will still helps us to open the file in another application, if the original > isn't present. So, I agree with Greg on this one. > > Should we move this to Mac OS X ?