Closed Bug 20223 Opened 20 years ago Closed 20 years ago

Space after last word effectively disappears with word-wrap

Categories

(Core :: DOM: Editor, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 19265

People

(Reporter: sidr, Assigned: ftang)

Details

* Overview:
If, when a word is wrapped to the next line, the previous word completely
fills out the line, the space that was typed between those two words cannot be
selected or cursored past. (If the line is not commpetely filled out by the
previous word, that space is visible, selectable, and can be cursored past.)
This interferes with revision of messages before sending them: insertion of
text or cutting and pasting of selections including the last word of a line
but not words on the next line is inconsistent. Words may be improperly
be joined upon further editing when a line is filled out.

* Steps to Reproduce:
1. Open a Message composition window (File>New>Message)
2. Type enough words that at least one word gets wrapped to the next line.
3. Press the [Backspace] key only enough times so that the last word goes
   back onto the previous line (Or, substitute step 3 with getting to this
   point the first time in step 2, as will happen randomly in ordinary use)
4. Press the spacebar and type another word, which will appear on the next line.
5. Press the left-arrow key enough times to return the caret to the beginning
   of the second line, and then press it once more to move it to the end of the
   first line (theoretically before the soft-newline and after the trailing
   space.
6. Type another word.
7. Move back to the beginning of the second line and press the left-arrow key
   once more so that the caret is at the end of the first line, after a space.
8. Type another word, of any length except that of the last word in step 3.


* Actual Result:
In step 6, the new word is joined to the last word on the first line, which
moves down to the second line because it is now too long, until the user adds
a space *before* the new typing, after noticing that. Also, it is impossible
to select the space that was typed following the last word. If a selection is
made including the last word of the first line, copied, and pasted elsewhere,
no space will appear after the last word or the pasted selection.

In step 8, the new word appears on the second line attached to the first word
of that line until the user types a space, which will happen naturally.

The inconsistency here is very annoying, and could lead to messages being
sent with words juxtaposed after editing a word-wrapped section of text
even though the user properly typed spaces after every word.

* Expected result:
The new word begins on the on the second line attached to the first word
of that line until the user types a space, whether or not the last word of
the first line filled out that line.

* Does not work correctly with:
1999-11-28-00-M12 nightly binary on Windows NT 4.0sp3
1999-11-19-09-M12 nightly binary on Windows NT 4.0sp3

* Additional Information:
This looks very much related to bug 19265 - the difference is that in the
Message Composer, the space that belongs at the end of the last word on the
first line essentially ceases to exist when there is no room for it on that
line, whereas in <textarea>s, the space appears at the beginning of the second
line - see bug 19265 for that.

A way of fixing both bugs would be to always wrap to the next line *after*
a space (or equivalent: &ensp; &emsp; &thinsp; &zwnj;), leaving a word on the
current line only if there is room for both the line and its trailing space.

This might make a long word-wrapped paragraph one line longer, but it would
preserve consistent edit-ability on a word-by-word basis no matter where
word-wrapping occurs. This would also make text at the right edge of the
editing area more readable by ensuring at least some whitespace to the right
of all lines.
Assignee: beppe → ftang
Frank - can you check and see if this is related to 19265?
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 19265 ***
Status: RESOLVED → VERIFIED
verified in 12/7 build.
You need to log in before you can comment on or make changes to this bug.