645771 - Editor mangles spacing to the point that patches are trashed

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Philip Prindeville]

I turned of "Compose in HTML" and sent myself the following message:

" foo"
" "
" bar"
" "

and then saved the message body out, and looked at it with "cat -v -e".

It was received as:

" foo"
""
" bar"
""

i.e. <space><newline> was transformed into <newline>.

There are several other high-profile bugs having to do with text being mangled that are either problems with the HTML serializer or else the editor, and are several months (or even years) old.  Those might take a while longer to fix.

This behavior is *very* specific, and directly blocks any workaround that might allow a TB user to submit patches inline without their being mercilessly mangled (and "no", using attachments isn't an option in the Linux kernel hacking community).

This should be reasonably simple to isolate and fix, as well as writing a canned regression test for so it doesn't happen again.

Comment 1

[Joe Sabash [:JoeS1]]

FWIW there is a way to retain the <space><newline>
Toggle both the following default prefs:
mailnews.display.disable_format_flowed_support
mailnews.send_plaintext_flowed

Compose in html mode, then send in plaintext with Options>>Format>>Plaintext

That's not to say this shouldn't be fixed, but there seems to be a "high barrier"
for fixes in this code area.

Comment 2

[Philip Prindeville]

(In reply to comment #1)
> FWIW there is a way to retain the <space><newline>
> Toggle both the following default prefs:
> mailnews.display.disable_format_flowed_support
> mailnews.send_plaintext_flowed
> 
> Compose in html mode, then send in plaintext with Options>>Format>>Plaintext
> 
> That's not to say this shouldn't be fixed, but there seems to be a "high
> barrier"
> for fixes in this code area.

Just to be clear: are you saying "mailnews.display.disable_format_flowed_support" affects how the message is *sent* and not simply how it is *displayed*?

Comment 3

[Philip Prindeville]

(In reply to comment #1)
> FWIW there is a way to retain the <space><newline>
> Toggle both the following default prefs:
> mailnews.display.disable_format_flowed_support
> mailnews.send_plaintext_flowed
> 
> Compose in html mode, then send in plaintext with Options>>Format>>Plaintext
> 
> That's not to say this shouldn't be fixed, but there seems to be a "high
> barrier"
> for fixes in this code area.

I just tried this and confirmed that the patch was still mangled.

Comment 4

[Joe Sabash [:JoeS1]]

Attachment: <space><newline> maintained

There are 2 unique prefs
The 2nd one "mailnews.send_plaintext_flowed" controls "adjustments" to the
composition prior to sending.
The first is how F-F is handled on display AFAICT
So for your use case, you would want to toggle them both.
mailnews.display.disable_format_flowed_support="true"
mailnews.send_plaintext_flowed="false"

Is this not the desired result?
(see attachment)

Comment 5

[Philip Prindeville]

(In reply to comment #4)
> Created attachment 522902 [details]
> <space><newline> maintained
> 
> There are 2 unique prefs
> The 2nd one "mailnews.send_plaintext_flowed" controls "adjustments" to the
> composition prior to sending.
> The first is how F-F is handled on display AFAICT
> So for your use case, you would want to toggle them both.
> mailnews.display.disable_format_flowed_support="true"
> mailnews.send_plaintext_flowed="false"
> 
> Is this not the desired result?
> (see attachment)

I'm not going by what the message looks like in my "Drafts" box but what it looks like as received in a test mailbox after sending.

Comment 6

[Joe Sabash [:JoeS1]]

(In reply to comment #5)

> I'm not going by what the message looks like in my "Drafts" box but what it
> looks like as received in a test mailbox after sending.

Oh you mean the X-Mozilla-Draft-Info: internal/draft headers, in the eml
That's because I used File>>send later , which in most cases performs the same serialization as if actually sent.
Just to be sure the "spacing" attachment added was actually sent and received.
Seems to preserve the spacing for me. (Windows os)

Comment 7

[Joe Sabash [:JoeS1]]

Attachment: spacing

Comment 8

[Thomas D. (:thomas8)]

Bug 778547 and Bug 662966 are similar, but not necessarily dupes.
At least in bug 662966 spaces are lost already in editor, whereas in this bug 645771 I understand they are lost after sending. But I might be wrong.

Comment 9

[Thomas D. (:thomas8)]

Bug 553277, Bug 806090