462126 - Attaching using Drag & Drop sets wrong Mime Type (text/plain)!

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[LarsV33]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2
Build Identifier: Version 2.0.0.17 (20080914)

When composing an email one can attach using menu/icon or drag&drop. The behavior however differs:

1)
When attaching a pdf file using the "paper clip" icon or the menu the mime type in the email is correct.

2)
When attaching using drag & drop the mime type will be set to text/plain and ignores the extension!

Reproducible: Always

Steps to Reproduce:
1. Compose new Mail.
2. Attach pdf by using drag and drop to the right upper part of the window.
Actual Results:  
Mime Type in mail is incorrect (text/plain).

Expected Results:  
Thunderbird should set the mime type like when using the attachment dialog. Since it correctly copies the filename including extension this should work.

I checked the mimetypes.rdf and it seems correct.

I also think that this bug might have been reported before but was usually rejected because it can only be reproduced when using drag and drop and this was not stated.

Comment 1

[rsx11m]

As you correctly mention, the assignment of a wrong MIME type is usually
caused by picking up an incorrect entry in mimeTypes.rdf, e.g., when opening
an attachment from a received e-mail containing such a wrong definition.

Now, the suspicious part is that you get a different result for using the attachment button versus drag-and-drop of a PDF attachment. In general, the mechanism should be the same, as drag-and-drop merely adds a reference to the file, which is then encoded and attached just before sending.

To make sure that mimeTypes.rdf is intact, could you attach the current version in your profile? This is located in "Documents and Settings", don't look at the template in "Program Files" which is only used for new profiles. Also, if you rename mimeTypes.rdf in your profile folder while Thunderbird is down, then restart it (it will be recreated from the tamplate), is the problem gone? If yes, chances are good that there *is* some wrong definition in it.

Comment 2

[LarsV33]

Attachment: broken mimeTypes.rdf

After renaming this mimeTypes.rdf the problem went away. :)

Comment 3

[LarsV33]

Nice, renaming the mimeTypes.rdf and letting Thunderbird generate a new one, helped. Thanks!

Anyhow, it's kind of strange since the mimeTypes.rdf does not even look broken and I have no idea how it got changed. Maybe an extension or a Thunderbird-Update screwed with it???

Thanks again!

Comment 4

[Phil Ringnalda (:philor)]

It's not broken in the sense of malformed, it's broken in the sense of broken-by-design: if someone sends you a mail with an attachment named foo.pdf with the mimetype text/plain, then we remember that and believe J. Random Emailer rather than asking your OS what type .pdf is, all because old Linux distros used to have terrible file associations.

Comment 5

[rsx11m]

(In reply to comment #3)
> Anyhow, it's kind of strange since the mimeTypes.rdf does not even look broken
> and I have no idea how it got changed.

Actually, it is broken, you have (had) two conflicting entries for "*.pdf"...

The correct entry is:

  <RDF:Description RDF:about="urn:mimetype:application/pdf"
                   NC:fileExtensions="pdf"
                   NC:description=""
                   NC:value="application/pdf"
                   NC:editable="true">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/>
  </RDF:Description>

But then you also have further down:

  <RDF:Description RDF:about="urn:mimetype:text/plain"
                   NC:description="Textdatei"
                   NC:value="text/plain"
                   NC:editable="true">
    <NC:fileExtensions>pdf</NC:fileExtensions>
    <NC:fileExtensions>txt</NC:fileExtensions>
    <NC:handlerProp RDF:resource="urn:mimetype:handler:text/plain"/>
  </RDF:Description>

which is followed by associating text/plain with Acrobat Reader:

   <RDF:Description RDF:about="urn:mimetype:externalApplication:text/plain"
                   NC:path="C:\Programme\Adobe\Reader 8.0\Reader\AcroRd32.exe"
                   NC:prettyName="AcroRd32.exe" />

Thus, this resolves the question of the how, apparently you've got a wrong message which associated ".pdf" with "text/plain" and opened it with Acrobat, which was subsequently registered in mimetypes.rdf (note the different syntax though for NC:fileExtensions between those entries). It seems to be arbitrary which version is used when attaching an x.pdf file, apparently the strategy differs indeed between using the menu or drag-and-drop to accomplish this.

Comment 6

[LarsV33]

(In reply to comment #4)
> It's not broken in the sense of malformed, it's broken in the sense of
> broken-by-design: if someone sends you a mail with an attachment named foo.pdf
> with the mimetype text/plain, then we remember that and believe J. Random
> Emailer rather than asking your OS what type .pdf is, all because old Linux
> distros used to have terrible file associations.

Actually, we are talking about sending and not receiving mails!

Comment 7

[LarsV33]

> Thus, this resolves the question of the how, apparently you've got a wrong
> message which associated ".pdf" with "text/plain" and opened it with Acrobat,
> which was subsequently registered in mimetypes.rdf (note the different syntax
> though for NC:fileExtensions between those entries). It seems to be arbitrary
> which version is used when attaching an x.pdf file, apparently the strategy
> differs indeed between using the menu or drag-and-drop to accomplish this.

Yes, it is very strange that the strategy differs based on the attachment method. This was the reason that I filed the bug because it was not obvious that mimeTypes.rdf could be the problem. :(

Comment 8

[rsx11m]

(In reply to comment #6)
> Actually, we are talking about sending and not receiving mails!

One causes the other, as explained in comment #5. At some point, you received
a message which had a text/plain ".pdf" file attached, this was opened and the wrong MIME type memorized. Whenever you attach a file to a message you send,
any entry in the mimeTypes.rdf file has a higher priority than whatever the operating system may suggest as being correct. Thus, it will happily use either application/pdf or text/plain as MIME type for outgoing attachments ending in ".pdf", where the only inconsistence is that it appears to depend on which mechanism is used. It may be just coincidence, but on the other hand, I'm not sure if this inconsistency would be a bug by itself. Rather, as hinted by Phil with "broken by design", it should be avoided that such a conflicting entry is included to start with.