567987 - Thunderbird picks wrong MIME type after renaming attachment file from .bmp to .txt

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[marsking]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

Renaming a graphic attachment to .txt causes thunderbird try to render it inline and nearly crashes it. No response to delete, no option to stop it from rendering or manipulate with the attachment.

Reproducible: Always

Steps to Reproduce:
1. drag a bmp file to attachment
2 [review]. rename x.bmp to x.txt
3. send
4. in sent box, click that email.
Actual Results:  
Thunderbird seems to render the attachment as txt content, and grinds to a halt.

Expected Results:  
We should be able to delete the email or manipulate with the attachment. Ideally, Thunderbird should detect it's not the correct mime and ask what a user want to do with it.

Comment 1

[Wayne Mery (:wsmwk)]

I can't reproduce a hang on vista with v3.1.1pre. what is size of x.bmp you are trying to send?

Comment 2

[rsx11m]

I can't reproduce the hang either with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5, but can confirm the inappropriate change of the Content-Type header to "text/plain" if the attachment is renamed before sent. This probably depends on when the MIME type is determined, and obviously this is done when sending rather than at the time the file is attached. Thus, given that the file association is based on the file name extension, the BMP file receives a text interpretation.

Comment 3

[marsking]

Sorry if I haven't made the steps clearer. I haven't tested arbitrary bmp files actually. What I did is like this:
1. Write an email
2. Drag this jpg: http://upload.ozbargain.com/2010/05/21/3832_21052010296.jpg to attachment. Although it's jpg, it has a .bmp suffix in the attachment window.
3. Rename it to whatever.txt
4. Send the email
5. In Sent box, click the sent email. It hangs there.

I'm using XP SP3.

Comment 4

[marsking]

Thunderbird also hangs if you click this email in inbox if you received it. That's why at first I thought it was a security problem.

Comment 5

[rsx11m]

(In reply to comment #3)
> Although it's jpg, it has a .bmp suffix in the attachment window.

Yes, this is bug 557708 - annoyingly, drag-and-drop from a 1.9.2+ browser recodes the image into BMP for some reason, blowing it up considerably (I'm getting a whopping 6579KB of encoded message with your example!). Thus, it may be just a matter of size exhausting some resources. Using 3.0.5, it takes a while but eventually displays the image. For the renamed text version, it seems to hang first (wheel not spinning), but occasionally updates the window. Thus, it's mainly busy with the rendering and therefore looks unresponsive (takes up almost 100% CPU for me). I ended up terminating the process.

To resolve the issue of not being able to delete the message or the attachment, disable View > Display Attachments Inline, then you can access the message without opening the attachment. I'm trying to figure out where the MIME type is actually set for an attachment, but MXR is currently unresponsive for me...

Comment 6

[rsx11m]

The performance issue for large text attachments is bug 210943, but this still leaves us with the file/type-association issue set wrong after renaming.

Retargeting and conforming for the latter part.

Magnus, it has been a while since bug 190298, but maybe you have some idea where this may go wrong.

Comment 7

[rsx11m]

Also observed on Linux. Possible relevant pointer after some code review:

> http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgSend.cpp#2180

nsMsgComposeAndSend::AddCompFieldLocalAttachments() determines the MIME type for local files (including those from drag-and-drop or temporary files) from the name or the extension of the "file:" URL, where the proposed name obtained by attachment->GetName(proposedName) takes preference over the name derived from the URL in msg_pick_real_name() [nsMsgCompUtils.cpp#1609].

fileUrl->GetFileExtension(fileExt); is tried first for the m_real_name, then for the URL itself. Thus, in cases where the name was modified, proposedName exists and therefore overrides the URL guessing. Either the original name should be preserved as additional field for the attachment to be available instead as the proposedName, or if the originally derived attachment name was modified the GetName() test omitted and only the URL used for the MIME type.

Comment 8

[rsx11m]

This could also be approached from the perspective where bug 271211 came
from, thus not allowing the attachment to use an ambiguous file extension.
The entered new attachment name could be sanitized to ensure that the file extension remains unchanged and/or is not mistaken as such. A respective function could look like this:

  function sanitizeFileName (aOriginal, aModified) {
    var lastOriginal = aOriginal.lastIndexOf('.');
    var extOriginal  = aOriginal.substring(lastOriginal);

    var lastModified = aModified.lastIndexOf('.');
    var extModified  = aModified.substring(lastModified);

    return extOriginal.toLowerCase() != extModified.toLowerCase() ?
           aModified.replace(/\./g, '_') + extOriginal : aModified;
  }

If only the part before the file extension is changed (e.g., "test.bmp" to "example.bmp"), that function returns the modified name as entered. However,
if they differ the front part is sanitized and the original file extension appended (e.g., "test.bmp" vs. "example.jpg" becomes "example_jpg.bmp").
This won't handle some special cases to defined when either the original or
the modified attachment name doesn't contain any extension at all (i.e., no
"." in the attachment name), or if an explicit removal of the file extension
by the user should be honored.

Or, as the third alternative, simply accept that the user changed the meaning of the attachment and pop up a warning message similar to what Windows Explorer does when the file extension is altered?