Open Bug 404321 Opened 18 years ago Updated 3 years ago

File contents which were in plain text are displayed as image/bmp

Categories

(MailNews Core :: Attachments, defect)

defect

Tracking

(Not tracked)

People

(Reporter: kiranmadival, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.6 and thunderbird-2.0.0.9 We have a plain text file with name t.sdf, which has the file content starts with "BM". When we send this file as an attachment in the seamonkey-1.1.6 and thunderbird-2.0.0.9 on RHEL, the file is treated and displayed as (Content-Type: image/bmp) image/bmp file, even though the file is being plain text file. But this problem does not occur on Novell's Evolution 2.0.2 email client. Use the following steps to reproduce.. Created a file, "t.sdf" with the following content. $ cat t.sdf bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0| $ And created a file, "t1.sdf" (File contents are in the Upper case) $ cat t1.sdf BMRSERVICE________ ABW MITT ABS RNA MV |RW|31.07.2007 |24:00 | 0| 9363| -3| 0| $ When we sent a mail with "t.sdf" as an attachment, E-mail client displayed the content type as text/plain. --------------070601060306090405080508 Content-Type: text/plain; name="t.sdf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="t.sdf" bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0| --------------070601060306090405080508-- When we sent a mail with "t1.sdf" as an attachment, E-mail client displayed the content type as image/bmp. --------------070805000704070809060102 Content-Type: image/bmp; name="t1.sdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="t1.sdf" Qk1SU0VSVklDRV9fX19fX19fIEFCVyBNSVRUIEFCUyBSTkEgTVYgfFJXfDMxLjA3LjIwMDcg fDI0OjAwIHwgMHwgOTM2M3wgLTN8IDB8Cg== --------------070805000704070809060102-- Also we also see that if the file content start with text "GIF8" the file being treated as "image/gif" $ cat g.sdf GIF8 $ and below how it is displayed by the Email Client. --------------060903070806030108010203 Content-Type: image/gif; name="g.sdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="g.sdf" R0lGOAo= --------------060903070806030108010203 Reproducible: Always Steps to Reproduce: Following steps to reproduce.. Created a file, "t.sdf" with the following content. $ cat t.sdf bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0| $ Created a file, "t1.sdf" (File contents are in the Upper case) $ cat t1.sdf BMRSERVICE________ ABW MITT ABS RNA MV |RW|31.07.2007 |24:00 | 0| 9363| -3| 0| $ When we sent a mail with "t.sdf" as an attachment, E-mail client displayed the content type as text/plain. --------------070601060306090405080508 Content-Type: text/plain; name="t.sdf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="t.sdf" bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0| --------------070601060306090405080508-- When we sent a mail with "t1.sdf" as an attachment, E-mail client displayed the content type as image/bmp. --------------070805000704070809060102 Content-Type: image/bmp; name="t1.sdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="t1.sdf" Qk1SU0VSVklDRV9fX19fX19fIEFCVyBNSVRUIEFCUyBSTkEgTVYgfFJXfDMxLjA3LjIwMDcg fDI0OjAwIHwgMHwgOTM2M3wgLTN8IDB8Cg== --------------070805000704070809060102-- Also we also see that if the file content start with "GIF8" the file being treated as "image/gif" $ cat g.sdf GIF8 $ and below how it is displayed by the Email Client --------------060903070806030108010203 Content-Type: image/gif; name="g.sdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="g.sdf" R0lGOAo= --------------060903070806030108010203 Actual Results: When the file contents were in plain text. The file content is treated and displayed as image/bmp file. Expected Results: When the file contents were in plain text. The file contents must be treated and displayed as text/plain file. This problem does not occur on Novell's Evolution 2.0.2 email client.
The problem happens at message composition/send time, not when the message is displayed, right?
I am experiencing this problem when the message is displayed in the mail client window. I have a filename with the extension sdf, and the file content starts with BM (all in Capital letters)and send this file as an attachment, Email client window displayed this as a Image. Why this is displayed as a image when the file contents are in plain text. When I looked at the below module "/modules/libpr0n/src/imgLoader.cpp" and the function name is imgLoader::GetMimeTypeFromContent() " /* Is it a GIF? */ if (aLength >= 4 && !nsCRT::strncmp(aContents, "GIF8", 4)) { aContentType.Assign(NS_LITERAL_CSTRING("image/gif")); ..... else if (aLength >= 2 && !nsCRT::strncmp(aContents, "BM", 2)) { aContentType.Assign(NS_LITERAL_CSTRING("image/bmp")); " The above piece of code checks for "BM" and sets the content type as "image/bmp". Why this has been done this way?. If I want to display the attachment as as plain text, what needs to be done? Let me know if you need more information on this.
I am experiencing this problem when the message is displayed in the mail client window. I have a filename with the extension sdf, and the file content starts with BM (all in Capital letters)and send this file as an attachment, Email client window displayed this as a Image. Why this is displayed as a image when the file contents are in plain text. When I looked at the below module "/modules/libpr0n/src/imgLoader.cpp" and the function name is imgLoader::GetMimeTypeFromContent() " /* Is it a GIF? */ if (aLength >= 4 && !nsCRT::strncmp(aContents, "GIF8", 4)) { aContentType.Assign(NS_LITERAL_CSTRING("image/gif")); ..... else if (aLength >= 2 && !nsCRT::strncmp(aContents, "BM", 2)) { aContentType.Assign(NS_LITERAL_CSTRING("image/bmp")); " The above piece of code checks for "BM" and sets the content type as "image/bmp". Why this has been done this way?. If I want to display the attachment as as plain text, what needs to be done? Let me know if you need more information on this.
Phenomenon was easily reproduced by: (lates-trunk 2007/11/18 build is used) (1) Preparation - No mime-type definition for file extension of ".1234" (When MS Win, HKEY_CLASSES_ROOT\.1234 doesn't exits in registry) - aaa-01.1234 : 4096 bytes of "A" (no CR/no LF) aaa-02.1234 : "BM" + 4096 bytes of "A" (== "BM" + aaa-01.1234) aaa-03.1234 : 4096 bytes of 0x19 aaa-04.1234 : "GIF8" + 4096 bytes of 0x19 (== "GIF8" + aaa-03.1234) (2) Compose a mail, attach above 3 files, send later. Following headers were created by Tb. > --------------000708080703050804060301 > Content-Type: text/plain; name="aaa-01.1234" > Content-Transfer-Encoding: base64 (<= this is because no CR/LF/CRLF) > --------------000708080703050804060301 > Content-Type: image/bmp; name="aaa-02.1234" > Content-Transfer-Encoding: base64 > --------------000708080703050804060301 > Content-Type: application/octet-stream; name="aaa-03.1234" > Content-Transfer-Encoding: base64 > --------------000708080703050804060301 > Content-Type: image/gif; name="aaa-04.1234" > Content-Transfer-Encoding: base64 Above is current implementation of fall back when unknown mime-type, as you see in program source. Simplest workaround is to register ".sdf" & "text/plain" to system table for file-extension=>mime-type translation. When MS Win, it is HKEY_CLASSES_ROOT\.sdf. Sorry but I don't know about Linux. (Why application who generates ".sdf" file doesn't register it to system?) (Server application, and your client machine does only read of the files?) Second workaround is to register ".sdf" & "text/plain" to mimeTypes.rdf of Tb. (A) Create entry for ".sdf"&"text/plain" in mimeTypes.rdf by Seamonkey's "Helper Applicasions", and copy back entries to Tb's mimeTypes.rdf. (This may be done by Firefox's latest-trunk, but I don't know well about it) (B) Create entry for ".sdf"&"text/plain" in mimeTypes.rdf via dialog by Tb. (B-1) Create a dummy received mail with attachment of ".sdf" and dummy mime-type (say "application/x-unknown") (B-2) Open the mail, and double click the attachment, and choose action(s). This forces creation on mimeTypes.rdf entry. (B-3) Terminate Tb, and edit mimeTypes.rdf, and replace "application/x-unknown" by "text/plain". (B-4) Restart Tb
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh sorry, you are fortunately using Seamonkey. Workaround is very very simple when Seamonkey. - Add ".sdf" & "text/plain" via Preference/"Helper Applications".
Assignee: mail → nobody
Component: MailNews: Main Mail Window → ImageLib
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: imagelib
Hardware: PC → All
Version: unspecified → Trunk
An alternative to GetMimeTypeFromContent should be used by mail clients. It's really only useful for discovering what type of image a particular thing that we highly suspect of being an image (i.e., a thing specified from within an <img> tag) is; using it as a general-purpose file(1) alternative is a bad idea.
Component: ImageLib → Attachments
Product: Core → MailNews Core
QA Contact: imagelib → attachments
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.