363624 - <end> on line ending with <space><LF> appears to place caret "before" space

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect, P4)

Description

[Mike Cowperthwaite]

TB 3a1; SM 1.5a.

There is an inconsistency between a line of text which is soft-wrapped and one where the wrap point is immediately followed by a hard newline.

Steps to reproduce:
1) Open plain text message compose window.
2) Type in a line of text ending with a printable character in wrap column:
   123456789 .... 123456789 ab    <-  'b' in column 72
3) Type <space>.  Observe position of caret.
4) Type cd, <up>, <end>.  Observe position of caret.
5) Type <enter>, <up>, <end>.  Observe position of caret.
6) Type ef.  Observe.
7) Type <bksp><bksp>.  Observe position of caret.
8) Type <bksp> again.  Observe position of caret.

Actual results:
3) Caret appears one space beyond the "ab" string.
4) Caret appears one space beyond the "ab" string.
5) Caret appears immediately right of "ab" string (no spacing).
6) "ef" immediately wraps to new line -- actual caret position was beyond the space.
7) Caret appears one space beyond the "ab" string.
8) Caret appears to the left of 'b' (!)

Expected results:
5) Caret appears one space beyond the "ab" string.
8) Caret appears to the right of 'b' (at end of line)

Apparently, if the line actually ends with  <space><LF>  (hard newline), the space is collapsed for the purpose of nav keys (end, right/left arrow treat it the same) but any changes made to the text (typing or bksp) result in the space being displayed.

However, if the text is soft-wrapped at that point, nav keys behave the same as typing.


This behavior has changed slightly since 1.8 branch (TB 1.5/2.0) (because of bug 235223?).  In the branch, the first space typed after column 72 doesn't appear at all, and flowed text behaves like unflowed: the caret never appears to the right of a space in column 73.  I like the way the change affects flowed text; I'd like to see a similar change for the line-ends-with-<space><lf>.  the primary reason for this is there is no way to tell whether the next letter you type is going to be concatenated to the word at the end of the line, or wrap to the next line.

(Note that there *is* a behavioral improvement even for this case: if you type <end>, the logical caret position is now after the space; previously, there was no way to get to that position.  If you wanted to merge the following line -- that is, remove the hard newline -- you had to type <end><space><del><del> instead of <end><del>.)


This may be related to bug 87314, where multiple typed spaces are collapsed once the wrap column is exceeded, but it's not quite the same.  For one thing, this bug doesn't apply to a textarea, it's specific to the wrapping imposed in plain-text mail compose.

Comment 1

[Uri Bernstein]

Probably related: Bug 335560 and bug 336408 (both regressions from bug 235223).

Comment 2

[Mike Cowperthwaite]

You're right, I think; those are related.  And now that I've looked at those, I see my last paragraph is wrong -- the behavior described here does occur in a textarea.  The difference is: when the caret is "to the right of the trailing space" -- which is the behavior I *want* in the plain-text mail compose window -- the cursor disappears in the textarea, as in bug 335560.

Comment 3

[Mike Schroepfer]

Plusing this for blocking since this appears to be a regression from a core bug

Comment 4

[Mike Cowperthwaite]

I'm not sure this needs to be blocking.  Looking into this with current trunk TB, the wrapping behavior is noticeably different: when you try to reproduce per the steps and get to step 2, typing the <space> causes a soft wrap before the "ab".  This changes the dynamics entirely.  I don't know if everything is fixed right, but this bug's symptoms no longer are visible.