Write an email. Use double spaces after periods. Let the messenger window wrap the text. Notice that if it wraps just after the period, the next line is indented once space. Kinda annoying. Not quite right. Strive, ever, for perfection. Cut & paste this text to test it. Noted with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020424. Could well be cross-platform, but I hate touching the Windows 2000 box...

Worksforme, linux trunk build 2002-05-12-08, plaintext composition mode. When wrapping immediately after a period, both spaces are kept at the end of the previous line... Are you using HTML composition or plaintext?

Note that you must RESIZE the window with text in it to see the problem. I'm using 100% default configuration (whatever that is), and File->New->Message. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020424

Ah, I see this, but indeed only in HTML mode. Plaintext mode is fine. I don't have to resize anything. Just typing spaces at the end of a line makes them show up on the next line.

I see this on Macintosh in Netscape 7 also. I am nominating this for editorbase since I think people run into it frequently and it's very ugly/confusing.

--> jfrancis

The editor doesn't know anything about where softwrapping occurs. And we have to use nbsp's (actually alternating spaces and nbsp's, usually) so it would take some pretty special layout code to achieve this. Back to kin, cuz i wuv him so!

Actually, there is one thing I could do that might help. I'll take this back and investigate...

I tweaked AdjustSelection() to be more aggressive about avoiding trailing nbsp's in runs of whitespace. This patch seems to work but it fires off lots of assertions. Just attaching as a WIP for now.

EDITORBASE+

I'm too sexy for this shirt. checkpointing more work. This is probably the real deal, or pretty close, but i need to seperate it out into multiple patches: I found a few other bugs on the way that had to be fixed.

Separating out the patch now. I had to make a bunch of changes to nsRangeUpdater. These changes now live in bug 178264.

candidate patch to nsHTMLEditRules.cpp and nsWSRunObject.cpp The two big comments in the nsWSRunObject.cpp file indicate the nature of the fix. I had to make creative use of <br>s once again to solve this problem, which is truly ironic given that the issue is *soft* wrapping.

Comment on attachment 105070 [details] [diff] [review] diffs for editor/libeditor/html r=glazman I don't like those trailing BRs but I can't think another cleaner solution backwards compatible with older browsers

forgot to mention minor comments like empty lines and indentation

Comment on attachment 105070 [details] [diff] [review] diffs for editor/libeditor/html sr=kin@netscape.com Just add an "is" in this comment: + // |<p>foo<br></p>bar| renders like |<p>foo</p>bar|. What this <br> addition + // buys us the ability to convert a trailing nbsp to a space. Consider:

Are you guys sure this only happens in HTML composition? I have been seeing this in plaintext email composition for some time. I have not noticed the wrapping error during composition, but you definitely can see it in the emails I have sent with Mozilla. In any email I have sent, when the end of a sentence is the last character, the next line (sentence) is indented by one space. I see this same behavior in Composer when I am writing web pages in HTML. Several of my web pages have this single-space indentation following a wrap after a period, exactly like emails I have sent. When I look at the source that Composer has generated, you can clearly see that it has inserted &nbsp's where I typed a regular (double) space (it shows one &nbsp; and one space following each period). Since this is exactly the same as how the plaintext editor in mail works, it seems that it is the same bug. I am using WinXP SP1. I have seen this in all builds I've been using in the last few months.

fix landed on trunk

*** Bug 178738 has been marked as a duplicate of this bug. ***

vrfy'd fixed on win2k and linux rh8.0 (2003.03.03) and mac 10.2.4 (2003.02.28), comm trunk bits.