Closed Bug 19492 Opened 20 years ago Closed 20 years ago

Trailing spaces of word-wrapped line: no visual indication

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sidr, Assigned: mjudge)

Details

* Overview:
During Message composition, it is impossible to see a selection of the last
space on a line. Additionally, cursoring past it shows inconsistencies
depending on whether the right-arrow or left-arrow key is used. This makes
adding a word to the end of a line work incorrectly.

* Steps to reproduce.
1. Open a Messagwe composition window (File>New>Message)
2. Type enough words that at least one word gets wrapped to the next line.
3. Use the left-arrow key to get back to somewhere in the last word of
   the first line.
4. Use the right-arrow key to return to the second line, one keystroke at a
   time to give time to observe.
5. Select only the last word on the first line including its trailing space
   by using shift-arrowkeys or shift-ctrl-arrowkeys.
6. Copy this selection, position the caret immediately before a word,
   and paste.
7. Carefully select only the last word on the first line *not* including its
   trailing space by using shift-arrowkeys or mousing.
8. Copy this selection, position the caret immediately before a word,
   and paste.

* Actual results:
1. In step 4, the caret moves to the next line immediately, not moving past
   the trailing space - it takes one too few keypresses to reach the next line.
   This is inconsistent with step 3, and makes adding words at the end of the
   first line impossible to do in the normal way: the first character typed
   will be added to the end of the last word.
2. It is hard to reliably know whether one is doing steps 5&6 or steps 7&8.
   In fact, to do step 5 with shift-right-arrow, the right-arrow key must be
   pressed exactly once after the last character of the word is selected;
   no visual indication is given.

* Expected Results:
1. The caret movement in step 4 will be congruent with that in step 3, the
   space will not be elided or hidden; it will be possible to add a word at
   the end of the first line without typing a space first.
2. It will be easy to do step 5 reliably as the trailing space will be visible.

* Tested with:
1999-11-19-09-M12 nightly binary on Windows NT 4.0sp3.

* Additional Information:
All of this is the same in the regular composer (Tasks>Compose).

If bug 14588 is fixed properly the first time, this may go away;
filing a new bug as this may not be true and more work may need to be done.
I'd also wait until the dust has settled after the fix for bug 16715 and
bug 17530 lands.

Entering Platform/OS as All/All as this is almost certainly XP; change
back to PC/WinNT if not.
None of this applies to <textarea>s - everything about trailing spaces works
as expected in <textarea> edit fields (using the same build).
The following could be a new bug, but it is surely related: if-and-only-if
the word-wrap happens when there is not room for another character on that
line in the edit field, it is *completely* impossible to insert after the space
following the last word on that line.

*Steps to Reproduce:
1. Open a Messagwe 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 steps 2 and 3 with getting to
   this point the first time)
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.

* 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.
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!

* 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-19-09-M12 nightly binary on Windows NT 4.0sp3

* Additional Information:
This could be a symptom of an algorithm that treats a terminal space as a
soft return if it is positioned at the right edge of the edit field, rather
than inserting a soft return after the space in the same circumstance.
Assignee: beppe → jfrancis
Target Milestone: M13
Actually, looking at this a second time, the second complete bug report here
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.
Assignee: jfrancis → mjudge
There may be multiple bugs being referreed to here (it's hard for me to tell),
but I'm assigning to mike on the basis of the first issue: inconsistency in
arrowing over whitespace at the end of lines.

Mike, is this fixed already?  I couldn't reproduce it.
Confirmed that the first issue cannot now be reproduced with 1999-11-28-08-M12
on WinNT; suggest resolving as WORKSFORME since jfrancis saw the same. It
probably got fixed along the way with a checkin for 16715 or 17530.

The second issue ( comment of 11/21/99 19:24 ) has been reported as bug 20223
with some additional detail; it should no longer be considered part of this
report.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
i agree this has been fixed now. goo team
Status: RESOLVED → VERIFIED
verified in 12/6 build.
You need to log in before you can comment on or make changes to this bug.