365282 - Thunderbird changes specified content type to text/plain when programatically sending email via javascript

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[cmtalbert]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: version 2 beta 1 (20061227)

On mac only, Thunderbird is not allowing javascript to send a "text/calendar" mime attachment. (Or any specified content type for that matter).  It changes the content type to text/plain before it is sent. However, on windows, this same code will work fine to send a text/calendar content type attachment. 

The code will be attached to the bug. 

Using Mac OS X 10.4.8 confirmed on PPC and Intel

Reproducible: Always

Steps to Reproduce:
1. On a mac, create a test run with the attached code
2. Send the email to yourself
3. Upon receipt, view the source of the message.
4. You will find that the ICS attachment has a content type of "text/plain" and not "text/calendar"
Actual Results:  
The content type is converted to "text/plain".

You can play with this and realize that any specified content type is ignored and converted to "text/plain".

Expected Results:  
You would expect this to behave as it does on windows, where the content type is "text/calendar" as you would expect. 


This is blocking lightning development for iTIP functionality.

Comment 1

[cmtalbert]

Attachment: Lightning Javascript code creating text/calendar attachment

This is a snippet of the lightning code that is attempting to create an email message with a "text/calendar" attachment part.  Hopefully it will aid you in creating a simple testcase for this bug.

Comment 2

[David :Bienvenu]

I'll try to look at this soon.

Comment 3

[Matthew (lilmatt) Willis]

Thanks David.  We're beating on this in #calendar if you need any help testing possible fixes.

Comment 4

[David :Bienvenu]

http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgSend.cpp#2364

this code forces us to snarf the attachment, which means we'll override the specified content type...I'll see if there's a way around that...

Comment 5

[David :Bienvenu]

Attachment: proposed fix

if the calling code (in this case, Lightning), has set the content type of the attachment, trust it. This will mean we won't convert it to apple double, but I'm told that newer apps don't create files that need encoding with apple double, and usually any code that's doing this attaching *and* is setting the content type will be creating their own file. Normally, the content type is *not* set by the calling js code.

Comment 6

[David :Bienvenu]

fixed on trunk and 2.0 branch.