Open Bug 587869 Opened 13 years ago Updated 6 months ago

CSV attachment displayed as text instead of opening in Excel


(Thunderbird :: Message Reader UI, defect)

Windows XP


(thunderbird3.1 ?)

Tracking Status
thunderbird3.1 --- ?


(Reporter: mike001, Unassigned)




(Whiteboard: [gs])

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 

Just-upgraded to 3.1.2, and can no longer open attachments containing CSV (comma-separated values) part.  Before upgrade to 3.1.2, used to open Excel.

Reproducible: Always

Steps to Reproduce:
1. Receive a multipart-mixed email with a "text/plain" part and "application/octet-stream" parts
2. Double-click to open the attachment
3 [review].
Actual Results:  
Attachment is displayed by TB as text.

Expected Results:  
Attachment will be opened by Excel

First part header:
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
[contains "body" of message]

Second part header:

Content-Type: application/octet-stream;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

May have same cause as Bug 587660.  Have full email available.

[again selected "Windows XP" as platform because I'm not sure what "NT 5.1" is]
[severity set at "normal", but if parsing "application/octet-stream" is broken, should be higher]
Whiteboard: [gs]
This is INVALID as Content-Type: application/octet-stream; name="P1YYMMDD.CSV" clearly doesn't say something like application/

Mike, does it work better is the attachment is named "P1YYMMDD.csv" ?
I don't think it's invalid, as -- according to the user -- this used to work.  From what I can tell, there IS code to handle "digging into" application/octet-stream attachments and deciding what to do based on the filename extension; see:

I don't know for sure that code ever gets involved when trying to display/save attachments, but I don't know what else it purpose would be.  I tried to figure out what MIME type would be returned based on a particular filename extension, but the "mapping" of extension-to-MIME-type is OS and user-dependent.  

Someone more familiar with where execution would proceed, given a particular filename extension, could probably determine if there were any changes in that area between early 3.x and 3.1.2.

If the filename/extension is case-sensitive, I'd say that's a bug (at least by my cursory examination of RFCs 2183 and 1521).

Finally, "This is INVALID as [...] clearly doesn't say something like application/"

No, it doesn't -- but it doesn't say "application/vnd.thunderbird", either.  If TB isn't supposed to try to open a compatible "AppHelper", then it certainly shouldn't display the attachment as text; the user should be asked if he/she wants to save the file.
I have the same problem : I want to open csv files with excel and txt files with notepad.

But both attachments are mime type Text/Plain. So Thunderbird always use the program associated with txt files.

The only solution I found is not to associate txt files with notepad. Each time I want to open a txt file, I have to confirm the message box (without prompting the option always do this action).

I tried to manually modify the file mimeTypes.rdf in my profile. But I don't find a solution.

If someone knows a better solution, I will use it.
I've found a work-around. As noted above, the problem is when a mail client marks the attachment as Text/Plain. Outlook handles csv attachments correctly (open in Excel) because Excel is a Microsoft product, so it presumably "just knows". To fix this for Thunderbird, the client must send the csv attachment as Content-Type: application/ Thunderbird, as a client, DOES do this.

I am using mail(x). To make this work with the mailx client, the following entry must exist in /etc/mime.types:

application/        csv

That did the trick for me. Other clients (e.g. mutt), also have mime.type settings.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.