User Agent: Mozilla/5.0 (Windows NT 6.0; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141106120505 Steps to reproduce: * Composed an HTML email (using Markdown plugin). The result HTML contains <code> elements, which are embedded in text, for example a string "test code", but longer (e.g. a dozen words). * Send email (with copy to myself). * Open the email in Sent folder. Actual results: The formatting of the text inside <code> element is broken. In original email, the entire <code> block would be inline in the text. In result email, the <code> element is span over several lines, I assume because of wrapping (as the rest of email body is also wrapped in the same way), and line breaks and spaces are then treated "as is" during display. Expected results: Thunderbird must send *the same* HTML which is displayed in Composer window. Either disable this converting/wrapping, OR, at least, make this conversion happen real time while I'm composing, so I can see that my email is broken before I send it out.

And here is an example of how that broken email looks like before I send it.

Another related bug is Bug 822741. My scenario above, and scenario in that Bug 822741 are representation of the same issue: Thunderbird re-formats HTML before sending, and author does not have a chance to even look at this re-formatted something until it's already too late to try correct it.

Tried with all add-ons disabled? (That mail looks like the markdown add-on changed the source...)

Pre-test to see Tb's behaviour. <code> is for inline code that can wrap. To preserve "New line" in <code>, it looks <pre><code> combination is needed, > http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets In Tb 31, following is observed. HTML Signture > <code>[CRLF] > AAA[CRLF] > BBB[CRLF] > </code>[CRLF] > > <pre>[CRLF] > <code>[CRLF] > XXX > YYY > </code>[CRLF] > </pre>[CRLF] Following is generated in <div> for Signature in composed HTML mail. > <div class="moz-signature">-- <br> > <code> > AAA > BBB > </code> > <pre><code> > XXX > YYY > </code> > </pre> > </div> This HTML is shown by Tb 31 : (a) View Message Body As/Original HTML > AAA BBB > > XXX > YYY (b) View Message Body As/Plain Text > | AAA BBB | > > | > XXX > YYY > | Because <code> is for inline code that can wrap, <code> AAA BBB </code> is identicl to "<code>AAA BBB</code>" in HTML. So, in generated HTML source by Thundebird, "<code> without <pre>" can be freely placed by Thunderbird.

Your problem is not observed in "(3) Style of <code> is removed from (2)". Do you use "white-space: pre-wrap" with correctly understanding it? > https://developer.mozilla.org/en-US/docs/Web/CSS/white-space > pre-wrap > Sequences of whitespace are preserved. Lines are broken at newline characters, at <br>, and as necessary to fill line boxes

In HTML souce generation at text/html part, Tb does do "Formating of HTML source". Split line at around 72 unicode characters. Add "5 to 6 spaces" at top of a line, in order to do Indention of HTML source. This is a known cause of "split at unexpect position of attribute value in HTML"(Bug 822741). Fortunately, it looks that Bug 822741 is irrelevant to this bug on <code>. If this "Formatting HTML source" is done on "<code> with style="white-space: pre-warp", this bug can happen. A workaround: Use <pre><code> combination to preserve new-line position and line length in <code>, instead of using "white-space: pre-warp" for <code>, as many places as possible.

Not respecting ux-wysiwyg is always a bad thing to do, and we can never expect users to use workarounds for that. HTML must always be sent as composed and seen on composition's screen.

> Bug summary : HTML is correctly shown in Compose window but is broken on send or saving in Drafts folder (involving <code>) As for "correctness in HTML", corect one is "mail display" and "confusing one" is display in composer : CSS Rule specified by user is not applied. This is pretty ordinal phenomenon because "composing HTML by a mailer" is rather similar to "HTML source editing by Text Editor" than "mail viewing while modifying HTML source".

I'm the author of the extension (Markdown Here) that incited the creation of this issue. > Do you use "white-space: pre-wrap" with correctly understanding it? Yes. I wanted user-inserted newlines in inline code preserved. (As requested by a user. Although I'm probably going to revert that to fix this on my end -- having Thunderbird email get randomly distorted is worse.) The general argument that it's a weird case to have a user directly modifying the HTML inline styles is somewhat compelling. However: 1) Tbird exposes the ability to do this to extension devs. And I'm sure mine isn't the only one that does it. 2) Doesn't pasting rich text bring inline styles with it? (Quick testing suggests yes.) So the problem isn't just "direct meddling with HTML", but also "pasting rich content from any web page". 3) As mentioned, breaking wysiwyg is bad. The problem here, as I see it, is that Tbird is pretty-printing -- that is, injecting newlines and spaces -- into email as it is sent without regard for any inline styles that might be present (such as `white-space`) that may result in distortion of the final email. (However, Tbird does seem to be aware of `pre` tags when pretty-printing and doesn't wrap the content.) Not that I have any idea what coding a fix in Tbird might be like, but... the easiest fix to me seems to be to stop pretty-printing the HTML. There's no upside to doing it that I can think of (although I bet there was a reason). Another fix would be to have the pretty-printer become inline-style aware. But that seems like a lot of work. Addendum: I just re-tested in Earlybird and... it's fixed?!? It seems that the pretty-printer is now white-space style aware. (The source differs depending on the presence of `white-space:pre-wrap` on the `code` tag.) So that's great.

Others and I just discovered this issue too. All I did was centered a section/paragraph. I did not bold, color, etc. SeaMonkey v2.33.1, in a very old updated Windows XP Pro SP3 machine, thought I was sending a plain text without asking. :(

Bad wrapping is due to the M-C serialiser. There are many bugs like this: Bug 822741, bug 1120825.