Closed Bug 20223 Opened 25 years ago Closed 25 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: 25 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.