541978 - Spaces before an "&" in signature are removed when sending (HTML to flowed-text conversion, seen with Delivery Format > Auto-Detect)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Ben Altman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

When there is a line in a signature file containing an "&", any spaces before it are stripped out *after* the email is sent. For example if the sig. file contains the line "Tom   & Jerry", when the message is being composed it appears correctly, but after receiving the email the line will appear as "Tom& Jerry". This came up for a particular company name which was a deal breaker for Thunderbird 3.0. Thunderbird 2.0.0.23 does not have the problem though.

Reproducible: Always

Steps to Reproduce:
1. Create a signature file for an account containing a line like "Tom  & Jerry" in it
2. Create a message in that account using the sig. file and send it to yourself or anywhere where you can see what is received.
3.
Actual Results:  
The signature line is received as "Tom& Jerry" with all spaces stripped out before the "&".

Expected Results:  
The line should remain as it was specified in the sig. file as  "Tom  & Jerry"

Comment 1

[Axel Reimer]

I can reproduce when I am using plain text:
OS: Windows 2000
Thunderbird 3.0.1

Sorry, this bug prevents me from switching to thunderbird.

Comment 2

[Ben Altman]

The problem occurs when the message body is plain text. The problem will not occur if the signature is typed out my hand at the end of the message. I.e. it has to be inserted as a signature file.

Comment 3

[rsx11m]

This looks like bug 448198, but that one is on quoting rather than composition from scratch, so maybe yet another regression from bug 215068.

Just to clarify: The signature file is plain text and the message is sent as plain text. Does it happen when composing in HTML? (or, if you compose in HTML and the message is converted to plain text during sending, do you also see it when composing directly in plain text?)

Comment 4

[Ben Altman]

When I did some tests earlier the message format had been set to "auto-detect" by default. When no special formatting was in the body of the message the bug occurred and when I did put formatting in, like making a character bold, it did not occur.

Comment 5

[Ben Altman]

The signature file contained only text. The original sig file contained a name and company address. My test sig file contained:
Ben  &  Jerry

Hello there
hi

Comment 6

[rsx11m]

Thanks, I can reproduce on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100125 Shredder/3.2a1pre with a plain-text signature. Also reproduced on SeaMonkey 2.0.2, Windows and Linux. Confirming.

Plain-text spaces before the '&' are added to the spaces after the '&', thus "a  &  b" becomes "a&    b" after sending in plain text. Spaces in an HTML signature if sent as HTML are retained, but the plain-text part of the message may show similar corruption. This is very similar to bug 448198 quoting issue.

Apparently it's the down-conversion from preformatted HTML to plain text which corrupts the signature (to a lesser extent it can also be forced in the message body, but it always keeps at least one space to the left of the '&', thus it is less obvious). I'm marking this dependent on bug 448198 as a solution there may provide a fix for this problem as well.

Comment 7

[rsx11m]

Bugzilla's line wrapping unfortunately screwed up my example, thus here again:

Plain-text original:       "a  &  b"
Sent in plain-text part:   "a&    b"

Comment 8

[Mike Cowperthwaite]

There is also a problem in HTML body text, but it's not identical.  If I compose an HTML message as:
----------cut---------
Ben  &  Jerry

-- 
Ben  &  Jerry
----------cut---------

the converted-to-f=f message reads:

----------cut---------
Ben &  Jerry

-- 
Ben&   Jerry
----------cut---------

Contrary to comment 7, I'm not seeing that the exact number of spaces is maintained: there is one space lost (a total of four spaces per line on input, a total of three spaces per line on output).  In the body, the one space is truncated before the '&';  in the sig, the one space is truncated and any remaining spaces moved to the other side of the '&'.

And this happens only when the plain text is format=flowed; turn off send-as-flowed and the plain text maintains the spaces as expected.

Comment 9

[rsx11m]

Thanks for adding this. Thus, disabling mailnews.send_plaintext_flowed in the Config Editor should suppress the issue (go into Tools > Options > Advanced > Genral tab, click on Config Editor, then copy-paste the preference name into the search bar. Double-click on the remaining entry to set it to "false" and then try again). This makes the formatting less nice but should serve as a workaround until the respective serializer bugs are resolved.

Comment 12

[Philip Prindeville]

I turned send_plaintext_flowed off and sent myself a patch, in Preformat.

I saved the message back out, and compared it to the original:

$ diff -u patch2 patch2_2 | cat -t -e 
--- patch2^I2011-03-28 00:58:28.000000000 -0700$
+++ patch2_2^I2011-03-28 00:58:21.000000000 -0700$
@@ -15,7 +15,7 @@$
  ^I^I^I^I^I size, le16_to_cpu(header->vpi),$
  ^I^I^I^I^I le16_to_cpu(header->vci));$
 @@ -1018,8 +1018,15 @@ static uint32_t fpga_tx(struct solos_card *card)$
- $
+$
  ^I^I^I/* Clean up and free oldskb now it's gone */$
  ^I^I^Iif (atmdebug) {$
 +^I^I^I^Istruct pkt_hdr *header = (void *)oldskb->data;$
@@ -29,5 +29,4 @@$
 +^I^I^I^I^I le16_to_cpu(header->vci));$
  ^I^I^I^Iprint_buffer(oldskb);$
  ^I^I^I}$
- $
 $


Lines with a single-space and then a newline are getting converted into just an empty line.

This *REALLY* does not work as expected when emailing patches around.

How did this EVER pass regression?

Comment 13

[Robert Sajan]

Just fyi I'm using Thunderbird 5.0 and this bug still exists as documented herein.

Comment 14

[rsx11m]

Yes, that's because there is no progress whatsoever in bug 448198, which would likely fix this and other related issues as well. No need to reconfirm this bug.

Comment 15

[Wayne Mery (:wsmwk)]

are the 3 newer bugs in this list duplicates?
https://bugzilla.mozilla.org/buglist.cgi?order=Bug%20Number&list_id=1098640&short_desc=flow%20spac&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&resolution=---&query_format=advanced&short_desc_type=allwordssubstr&type0-0-0=nowords&value0-0-0=count%20counts&product=MailNews%20Core&product=Thunderbird

Comment 16

[Paolo Bonzini]

Dup of bug 597181, not really related to signatures.

Comment 17

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.