Open
Bug 765866
Opened 12 years ago
Updated 2 years ago
white space wraps differently in sent message than in composition window
Categories
(MailNews Core :: Composition, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: NotR, Unassigned)
Details
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•12 years ago
|
||
Confirming for tb13/winxp
Updated•11 years ago
|
Component: General → Untriaged
Comment 2•11 years ago
|
||
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•11 years ago
|
||
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?
Reporter | ||
Comment 4•11 years ago
|
||
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>
Reporter | ||
Comment 5•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
(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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•11 years ago
|
Component: Untriaged → Composition
Product: Thunderbird → MailNews Core
Comment 8•11 years ago
|
||
(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•11 years ago
|
||
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)
Reporter | ||
Comment 10•11 years ago
|
||
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
Reporter | ||
Comment 11•8 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•