If I forward a message as an attachment, it gets a content type of text/plain instead of message/rfc822. This causes the message source to be displayed when the recipient gets the message, instead of seeing the message displayed as a message.

this fixes the problem for me. However, this code has been broken for a long time (since 2004) so something has changed that causes us to hit this branch of code where we didn't before. I'll try to figure that out as well...

fixed

Adding "instead of message/rfc822" to summary for ease of search.

(In reply to comment #1) > something has changed that causes us to hit this branch of code where we didn't before. Can patch of Bug 383485 Comment #3 explain it?

if you mean the problem fixed by the patch in bug 383405, I guess that's possible. However, I used html compose by default anyway, so it's not obvious why that would be related.

(In reply to comment #5) > if you mean the problem fixed by the patch in bug 383485 Sorry but I can't check it by test, because your patch for this bug is earlier(on 6/05) than Boris's one(on 6/06). So that's simply my guess.

Hey David, I don't think this is the right fix. This patch breaks vcards and other attachments. We end up setting them to plain/text instead of the appropriate mime type for the attachment. + if (!strcmp(aContentType, "multipart/appledouble")) #endif { PR_FREEIF(ma->m_type); ma->m_type = PL_strdup(aContentType); } This change makes it so only attachments that have a content type of multipart/appledouble, get a value for ma_>m_type. When the attachment type doesn't get a content type set on it, we assume plain/txt. To test send yourself an e-mail with a vcard. Backing out this change fixed it for me.

Scott, you must be right. I'll try to figure out why forward as attachment is broken...

this fixes both cases - I'll go debug 2.0 and figure out why 2.0 works w/o any of these changes.

the problem was that we were passing in the emtpy string instead of a null string, in some cases. So I converted the code to use nsACString & and check for empty strings.

Comment on attachment 267603 [details] [diff] [review] proposed fix argh, that didn't work - clearing request

Comment on attachment 267603 [details] [diff] [review] proposed fix false alarm - this seems to work fine.

Comment on attachment 267603 [details] [diff] [review] proposed fix >Index: public/nsIURLFetcher.idl >=================================================================== > typedef nsresult (*nsAttachSaveCompletionCallback) (nsresult aStatus, >- const char *aContentType, >- const char *aCharset, >+ nsACString &aContentType, >+ nsACString &aCharset, Why not const nsACString& for those two?