765866 - white space wraps differently in sent message than in composition window

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Glenn Knickerbocker]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20100101 Firefox/10.0.4
Build ID: 20120420145309

Steps to reproduce:

In the plain text composition window, when a line ends with two or more spaces that extend past the wrap point, the next line is displayed starting with the first nonblank in column 1.


Actual results:

When the message is sent, the line is instead wrapped at the first space, leaving additional spaces at the start of the next line.


Expected results:

Whichever way the white space is treated, it should be the same between the composition window and what is actually sent.

I think the current behavior in the composition window makes more sense.  If I want a line to start with blanks, I'd expect to have to put an explicit carriage return before it.

Comment 1

[Thomas D. (:thomas8)]

Confirming for tb13/winxp

Comment 2

[WADA:World Anti-bad-Duping Agency]

Problem relatd to Bug 168420?

(In reply to Glenn Knickerbocker from comment #0)
> In the plain text composition window, 
> when a line ends with two or more spaces that extend past the wrap point, (snip)

Bug 155015 is for similar case, and was closed as dup of bug 125928(Target Milestone: mozilla 1.9beta1).
> Bug 155015 format=flowed and lines with 2+ spaces at the end
Regression of that bug? Or absolutely different problem in similar condition?

Comment 3

[WADA:World Anti-bad-Duping Agency]

Format=flowed is defined by RFC3676.
> http://tools.ietf.org/html/rfc3676
In it, line ending with [SP][CRLF} is defined as "soft line break", and [NonSP][CRLF] is deined as "hard line break"="end of paragraph"="start of next paragraph".
For generation of "soft line break", two ways are defined.
(i)  insert [CRLF] after a space in text, and format=flowed,delsp=no.
(ii) insert [SP][CRLF] in text, and format=flowed,delsp=yes.
In any way, there is no way to generate "[SP] + hard line break" in format=flowed.

> Expected results:
> Whichever way the white space is treated, it should be the same between
> the composition window and what is actually sent.

If it's your intention, why you send mail with format=flowed?
(even if you don't intentionally use format=flowed, as far as default of a mail software is format=flowed, "use without setting change" is your choice of "format=flowed".)

If such formatting including line break or spacing is so important for you, why you don't utilize HTML mail which has capability to request Paragraph, Carriage return+Line feed, No-breakable-space( ) etc. explicitly?

Comment 4

[Glenn Knickerbocker]

The problem is with non-flowed plain text that's hard-wrapped on sending, not format=flowed.

If I type:

<pre><u>
123456789 123456789 123456789 123456789 123456789 123456789 123456789 1  123456789
</u></pre>

It's displayed in the composition window as:

<pre><u>
123456789 123456789 123456789 123456789 123456789 123456789 123456789 1 
123456789
</u></pre>

but it's sent in the message as:

<pre><u>
123456789 123456789 123456789 123456789 123456789 123456789 123456789 1
 123456789
</u></pre>

Comment 5

[Glenn Knickerbocker]

(Never mind the HTML above--I was just hoping I could highlight the presence or absence of a blank at the end of the wrapped line.  But that's actually a different issue that I don't think needs to be addressed with this bug.  I would have expected *all* blanks to collapse at the wrap point, and *no* blanks to collapse at the end of unwrapped lines.  Instead, only *one* blank collapses at the wrap point, and *all* blanks collapse at the end of unwrapped lines.)

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Glenn Knickerbocker from comment #4)
> The problem is with non-flowed plain text that's hard-wrapped on sending,
> not format=flowed.

If so, difference between wrap in typed string display in composition window(controled by mail.compose.wrap_to_window_width=true/false, default is false) and wrap in sent plain/text mail data without format=flowed by mailnews.wraplength(default=72 bytes)?

What is your mail.compose.wrap_to_window_width setting?
If true, phenomenon varies by composition window width change?

Perhaps answer is no...
I could observe phenomenon.
  Tb 17.0.2 on MS Win-XP
  mail.compose.wrap_to_window_width=false (deault)
  mailnews.wraplength=72 (default)
  Plain text mail composition
  Paste a line of [12...9+SP]*7+[1]+[SP][SP]+[12...9][CRLF]
    => display of 1st line ends with "123456789[SP][CRLF]"
    => display of 2nd line starts with "1[SP][SP]123456789"
    Wrapped at 71 bytes? Or at word boundary before 72 bytes?
  Send Later:
    charset=iso-8859-1  : sent in format=flowed.
      => 1st line in message source ends with "123456789[SP]1[SP][CRLF]".
      => 2nd line in message source starts with "[SP][SP]123456789".
    charset=iso-2022-jp : sent in non format=flowed.
    (format=flowed is disabled internally because delsp=yes is not supported yet)
      => 1st line in message source ends with "123456789[SP]1[CRLF]".
      => 2nd line in message source starts with "[SP]123456789".

It looks;
  (a) When format=flowed:
      [SP][CRLF] is inserted after "[SP]1" which is placed at 70/71 bytes,
      but delsp=yes is not set.
      Note: Upon display of mail, [SP][CRLF] of first line looks removed.
  (b) When non format=flowed:
      Wraped at 72 bytes as expected, by mailnews.wraplength=72.
      Last space just before [CRLF] in first line is removed.

Due to "insertion of [SP][CRLF] without delsp=yes by (a) for format=flowed", non format=flow code wrongly tries to remove [SP] just before [CRLF] of first line?

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. from comment #1)
> Confirming for tb13/winxp

Me too, for Tb 17.0.2/winxp. Thomas D. why still UNCONFIRMED?

Comment 8

[Thomas D. (:thomas8)]

(In reply to WADA from comment #7)
> (In reply to Thomas D. from comment #1)
> > Confirming for tb13/winxp
> 
> Me too, for Tb 17.0.2/winxp. Thomas D. why still UNCONFIRMED?

Sometimes I don't confirm reproducable ("confirmed") bugs when I don't have time to check for duplicates :)

Comment 9

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 125928(to which Bug 155015 was duped) looks changed to FIXED by fixing of bug 215068. Patch for bug 215068 touches nsPlainTextSerializer.cpp.
> Bug 215068 - leading spaces are lost (HTML compose, plain-text send)

Comment 10

[Glenn Knickerbocker]

In TB24 this is changed but not fixed.  Now, my long line with two blanks is displayed in the composition window as:

123456789 123456789 123456789 123456789 123456789 123456789 123456789 
1  123456789

but it's still sent in the message as:

123456789 123456789 123456789 123456789 123456789 123456789 123456789 1
 123456789

Comment 11

[Glenn Knickerbocker]

TB45, wrap is now correct on sending:

123456789 123456789 123456789 123456789 123456789 123456789 123456789 1
123456789

but still not on display:

123456789 123456789 123456789 123456789 123456789 123456789 123456789 
1  123456789