If I compose a message to myself with the preformat text message body: this & that it is sent as "this& that" instead. This does not happen with "body text" formatting.

This looks like another fall-out from bug 215068, also see bug 448198. If my guess is right, it should be worked around by disabling flowed format. Bypassing it will create "hard" line breaks, but may avoid the issues caused by that bug. 1. Click on Config Editor in Tools > Options > General > Advanced. 2. Copy-paste mailnews.send_plaintext_flowed into the search bar. 3. Double-click on the remaining entry to toggle it to "false".

This looks very similar to bug 541978 on signatures, with plain-text signatures being included in preformat style, so this would match in behavior.

Did this fall off the radar?

(In reply to comment #3) > Did this fall off the radar? You never replied to comment 2 nor 1

(In reply to comment #4) > (In reply to comment #3) > > Did this fall off the radar? > > You never replied to comment 2 nor 1 Comment #2 wasn't a question. I'll try to look at comment #1 later.

(In reply to comment #1) > This looks like another fall-out from bug 215068, also see bug 448198. > > If my guess is right, it should be worked around by disabling flowed format. > Bypassing it will create "hard" line breaks, but may avoid the issues caused > by that bug. > > 1. Click on Config Editor in Tools > Options > General > Advanced. > 2. Copy-paste mailnews.send_plaintext_flowed into the search bar. > 3. Double-click on the remaining entry to toggle it to "false". So this only seems to happen when "flowed" is true, and using Preformat. If I enter: a <-> b <-> c input -> output I get back: a<-> b<-> c input -> output

I'm raising the importance of this bug for two reasons: (1) we have adequate automated regression testing that this never should have been allowed to slip into a shipping version; (2) if, as I do, you submit Linux patches you know that they can't be done as attachments and they absolutely can't be mangled in any way or they won't apply via "patch", and hence will be rejected. This last bug has been plaguing me for about 6 months now, to the point that I'm considering abandoning using TB (which I contribute to, and don't consider lightly) until this insanity can be dealt with. Please someone assign themselves this bug and FIX THIS. I'd do it myself but it's way outside of my expertise, and I'd probably introduce even more damage.

Just to make it clear, arrow signs (greater than and less than) and ampersands cause this - you just cannot do this when passing code around, never mind TB corrupting messages! That's a no-no. It fails in Windows as well.

I think this could never happen if we preserved <pre> and <tt> as HTML, instead of {Delivery Format > Auto-Detect} wrongly downgrading the message to plaintext format=flowed. See related bug 414299 against auto-detect downgrading of messages having <tt> to plaintext, so both <tt> and <pre> get lost when sending. <pre> is also discussed there. I'm not sure if this still happens, wfm on TB17.0.7 / WinXP, both for ampersand and angle brackets, but reported against MAC OS. WADA, can you still reproduce this issue?

> WADA, can you still reproduce this issue? I don't know difference among followings. (a) text/plain part under multipart/alternative, which is sent by Format="Rich Text(HTML) + Plain Text". Coverted to text by ordinal HTML2text converter? Downgraded by Auto-Detect? (b) Relevant string in HTML compsition => change to Format=Plain Text => changed to Text mode. Coverted to text by ordinal HTML2text converter? Downgraded by Auto-Detect? It's perhaps not absolutely same as Text mode composition since initial. (c) text/plain mail which was downgraded by Auto-Detect. And, I'm not interested in text/plain mail down-graded by Auto-Detect. Answer is: I don't know anything about I can reproduce or I can not reproduce.