Last Comment Bug 363764 - .vcs files (and sometime rtf files) get sent as text/plain
: .vcs files (and sometime rtf files) get sent as text/plain
Status: REOPENED
: fixed1.8.1.1
Product: MailNews Core
Classification: Components
Component: Attachments (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: David :Bienvenu
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-13 14:59 PST by David :Bienvenu
Modified: 2010-11-12 02:19 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
proposed fix (1.38 KB, patch)
2006-12-13 15:03 PST, David :Bienvenu
mscott: superreview+
Details | Diff | Splinter Review

Description David :Bienvenu 2006-12-13 14:59:19 PST
There are some files that look like text but don't display well as text. In particular, I know of two - .vcs files and .rtf files. We should be setting their content type as application/octet-stream, I believe. There are a lot of ways of doing this, but for now I've picked a way that only affects send time...

For the rtf case, you need an rtf file that's big enough so that the unknowndecoder's quick check will pass (rtf files end with a non-text char, but if the file is small enough, the unknown decoder will notice that non-text char). > 20K ought to do it.
Comment 1 David :Bienvenu 2006-12-13 15:03:53 PST
Created attachment 248568 [details] [diff] [review]
proposed fix

if there are more of these file types, we should make this into a table, I suppose...

I didn't want to mess with registry settings or mime type tables - this is a send time thing, and it really doesn't matter how you've configured things; it's up to the recipient...
Comment 2 David :Bienvenu 2006-12-15 09:11:40 PST
fixed on trunk and 2.0 branch
Comment 3 Mike Cowperthwaite 2006-12-16 10:35:17 PST
David, I wish you'd CC'd me on this.  This solution makes me unhappy.  If you're not willing to create a table of useful MIME associations, why bother making the patch?

.RTF files should be either application/rtf or text/rtf.  text/rtf is recognized (somewhere [1]) by Moz as a type that should not be displayed inline; I think it's the type preferred by Microsoft (who own the format after all).  But if this is just a fallback measure, application/rtf is probably a better approach.  I'm running Ubuntu at the moment, and my current config (with TB 1.5.0.8) is assigning application/rtf.

I found the following for .VCS:
  application/hbs-vcs 
  text/calendar 
  text/x-vcalendar

/netwerk/mime/public/nsMimeTypes.h  has a definition for text/calendar.  That seems to make it the obvious type to use.

I'm assuming the |if (type.IsEmpty()...)| part of the patch means that this is done after all previous attempts to identify have completed, right?  That is, you're not overriding an entry from mimeTypes.rtf?


[1] I did an LXR search for "/rtf" and the only instances I found were comments in os2-specific code.  But I've tested this, and a text/rtf attachment is not inlined, unlike random text/* types (such as text/yo-mama).


(In reply to comment #1)
> I didn't want to mess with registry settings or mime type tables

Why not?  I think patching mimeTypes.rdf would have been a more useful way to approach this, but there doesn't seem to be any precedent for putting anything at all in there by default (e.g. text/x-moz-deleted -- see bug 286454).


> this is a send time thing, and it really doesn't matter how you've
> configured things; it's up to the recipient...

What if the recipient happens to be on an identical system which is likewise (for some reason) ignorant of these MIME types?  When the recipient gets this message, she won't be able to associate a default action for handling it -- not even Save -- because it's application/octet-stream.
Comment 4 David :Bienvenu 2006-12-17 08:28:27 PST
Sorry, Mike, I thought you were automatically cc'ed on everything mailnews.

>I'm assuming the |if (type.IsEmpty()...)| part of the patch means that this is
>done after all previous attempts to identify have completed, right?  That is,
>you're not overriding an entry from mimeTypes.rtf?

Yes, exactly. It's a last ditch attempt to make sure we don't send these types as text plain.

I'm happy to try to make those changes...
Comment 5 David :Bienvenu 2006-12-17 08:29:09 PST
cc'ing Mike - see previous comment.

Note You need to log in before you can comment on or make changes to this bug.