Closed Bug 633493 Opened 13 years ago Closed 5 years ago

Signature separator not recognised in format=flowed messages

Categories

(MailNews Core :: MIME, defect)

1.9.2 Branch
x86_64
Windows 7
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Roger, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11

Seamonkey doesn't recognise the <newline><dash><dash><space><newline> ("-- ") signature separator in email sent with format=flowed.

It doesn't fade the signature when viewing the email and it doesn't strip the signature when quoting the email in a reply which is does when viewing a normal (not f=f) email.

Reproducible: Always

Steps to Reproduce:
1. Receive a format=flowed email with a signature separator
2. View it
3. Reply to it
Actual Results:  
The signature separator and the text after it are displayed normally.

Expected Results:  
When viewing the email the text after the signature separator should be faded and when replying the text after the separator should be stripped from the quoted message in the reply, like it does when reading a normal email.

This also happens to my colleague using Thunderbird 3.1.7. He insists that it used to work until recently.

I have format=flowed disabled in Seamonkey.
I'm moving this to MailNews Core as it affects both Thunderbird and SeaMonkey, and indeed much of the signature handling is shared backend code.

Testing with the Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.17) Gecko/20110123 SeaMonkey/2.0.12 release candidate, I don't see any differing behavior in signature display and during composition with plain-text mails. Signatures are grayed when viewed and removed when replying to the message. Flowed format is enabled for both sending and displaying, and I don't see any difference with mailnews.display.disable_format_flowed_support = "true".

There are a couple of known bugs with signatures not being recognized when using the HTML part, but to the extent of my knowledge there are no recent changes or fixes in this regard.

Do you see this behavior with pure plain-text messages? Toggling View > Message Body As between Plain Text and the HTML options shouldn't change the display.

Maybe are there any add-ons installed that could interfere? Check the list in Tools > Add-on Manager > Extensions, anything related to signature handling?
Component: MailNews: General → MIME
Product: SeaMonkey → MailNews Core
QA Contact: mail → mime
Version: unspecified → 1.9.2 Branch
Sorry for not following up on this.

Looking back I can't find any examples of it happening with pure plain text messages, although I thought I had seen that when I reported the bug, so it does seem to only happen with multipart/alternative html messages.

However I have found an example of a multipart/alternative html message where the signature is recognised, so it does sometimes work.

If there are known problems with recognising the signature in multipart html mails then this bug is probably a duplicate. Sorry for the noise.
I am about to install Seamonkey 2.1 RC1, so I will check if anything has changed.
I have just come across this bug again, and it's probably related to multipart/alternative html messages.

I have received a multipart html message from Thunderbird 24.4.0. The plain text part contains "-- " followed by a newline. The html part contains "    <div class="moz-signature">-- <br>" followed by a newline.

I am viewing and writing in plain text. When viewing, the signature is not displayed in grey, and when replying, the signature is not removed from the quoted text.

I am now using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 SeaMonkey/2.25

I can't reproduce this in TB 68. If you think the problem is still there, please attach a sample message that will show the problem.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.