994098 - Plain text attachment file name name gets glued together with the first line of an attachment in a plain text email

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[Tero Nieminen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20140316052404

Steps to reproduce:

When opening for reading an plain text email with plain text attachment either received or sent by Thunderbird itself (ie. in Sent folder).

My view settings: Message body as plain text, Display attachments inline



Actual results:

The file name of a plain text attachment gets glued at the beginning of the first line of the actual attacment. Also there is no empty line after a (plain text) signature. All this makes it look a rather confusing as if the message didn't parse correctly.



Expected results:

The attacment file name ought be separated from the actual attachment content (and preferrably from the signature also) for legibility.

This seems to be a display only bug, though: the attachment itself is not affected and Thunderbird can manipulate (save/open) the attachment without problems.

Comment 1

[Tero Nieminen]

This bug occurs on a RHEL Desktop 6.5 with distro supplied Thunderbird 24.4.0-1.el6_5 (formerly Tbird ESR).

Comment 2

[WADA:World Anti-bad-Duping Agency]

There is no need of lengthy description about problem, if problem is "different display result of a mail from your expectation" and if the problem is 100& re-producible(problem always occurs on a specific mail), because any mailer shows mail content based on mail data stream==data of message source.
Mandatory information is:
- mail data file which was saved as .eml
- screen shot of mail display in your environment, with crisp description about "what is wrong"

Can you attach .eml file to this bug?

Because problem on "attachment part", other headers such as Subject:, From:, To:, Received: etc. is irrelevant to problem. Edit .eml file by Text Editor, remove irrelevant lines, replace or remove private data or confidential data from .eml file, before attach the .eml file to this bug, please.

Comment 3

[Tero Nieminen]

Attached below are a sample email and a corresponding screenshot demonstrating the bug: attachment name and the contents of the attachment are just catenated together.

Comment 4

[Tero Nieminen]

Attachment: A sample email

Comment 5

[Tero Nieminen]

Attachment: A screenshot of the display problem

Comment 6

[WADA:World Anti-bad-Duping Agency]

Following in message body,
> --[CRLF] 
> SIG[CRLF]
> [CRLF]
and "sample.txt" of filename="sample.txt", and "Lorem ipsum dolo..." in attaced text file data,
looks merged.

If signature, "--[SP][CRLF]".
Tb uses "--" as heading of file name line of attachment.
Tb confuses "--" in message body as "heading of file name of attachment"?

Comment 7

[Tero Nieminen]

Just to make sure there's no confusion: the signature separator in the attached email is *not* missing the space before [CRLF] (as may be interpreted from the above quote).

Comment 8

[WADA:World Anti-bad-Duping Agency]

Unable to reproduce your problem with attached mail,in Tb 24.4.0 on Win-XP.
Following is BODY.innerHTML object data in chrome message pane which is obtained by DOM Inspector.
> <div class="moz-text-plain" wrap="true" graphical-quote="false" style="font-family: -moz-fixed; font-size: 13px;" lang="x-western">
> <pre wrap="">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
> 
> <div class="moz-txt-sig">-- 
> SIG
> </div>
> 
> </pre>
> 
> </div>
> 
> <br>
> 
> <fieldset class="mimeAttachmentHeader">
>   <legend class="mimeAttachmentHeaderName">sample.txt</legend>
> </fieldset>
> 
> <br>
> 
> <div class="moz-text-plain" wrap="true" graphical-quote="false" style="font-family: -moz-fixed; font-size: 13px;" lang="x-unicode">
> <pre wrap="">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
> </pre>
> </div>

<br>, <fieldset etc. are rendered as expected, and is displaye like next.
> --
> SIG
> 
> 
> -- sample.txt -------- ... -------- (not ascii hyphen, horizontal bar like display)
> 
> 
> 
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do ...

What Theme do you use? Do you see your problem with Tb's -safe-mode?
Do you alter CSS rules which is used by abobe code by userChrome.css or userContent.css?

Comment 9

[Tero Nieminen]

Using default theme. In safe-mode display is ok.

The culprit seems to be add-on "Quote Hightlight 1.07".

Problem solved.