96704 - After a cut, left/right arrow moves caret wrong

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect)

Description

[Brent]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010815
BuildID:    2001081504

In the box used to type this report, if text is selected (with the mouse)
starting from past the last character in a line, and then deleted, left and
right arrow do not move the carat correctly.

Reproducible: Always
Steps to Reproduce:
In a text box,
1. type, with carriage returns at the end of the 1st two lines:
one
two
three
2. With the mouse, highlight (hold down on left mouse button to highlight) "thr"
by positioning the pointer far to the right of the 'o' in two and then moving
the pointer down and left until "thr" is selected.
3. Hit Delete.  Should have:
one
twoee
4. Hit Right Arrow.  Carat moves to position between 't' and 'w'.
Or 4. Hit Left Arrow.  Carat moves to end of "one".

Actual Results:  Carat is in the wrong place.

Expected Results:  Carat should move right or left one position.

Sometimes the carat moves a few pixels to the right when the left mouse button
is first clicked beyond the end of a line.  This is the same movement often
caused by the End key.

Comment 1

[Kathleen :Brade]

-->jfrancis

Comment 2

[Joe Francis]

Step 4 of desired results is wrong.  

When I try this test case, I get the "real" expected behavior: caret is between o 
and e of "twoee", and moves one character for each arrow key.

Comment 3

[Brent]

This bug did not happen in the editor used to compose e-mail messages.  This bug
DOES happen in a text editing box in a browser window, such as the one used to
write this Additional Comment.
Just checked build 2001082703 on Windows 98 2nd ed.  The bug is still there.

Clarifications
step 1: type "one<Enter>two<Enter>three".  Should have:
one
two
three
step 3:  Carat is positioned between 'o' and 'e' of "twoee".
step 4:  Left and Right Arrow move carat as if carat was positioned before the
't' in "twoee"

Comment 4

[Joe Francis]

I did indeed test this in a browser textarea widget.  I believe you but I don't 
see the problem on my machine.  Anyone else seeing this?

Comment 5

[Brent]

This bug also occurs under Linux.  Tested build Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:0.9.3) Gecko/20010801.  Can't see how this could be a hardware prob,
but FYI, I used the same computer to test under Windows 98 and Slackware 8.0
Linux distribution with Linux kernel 2.4.9 and XFree86 Version 4.1.0 set to
"vga=791" which is 1024x768x64K colors in generic VESA graphics mode.

Comment 6

[xyzzy]

Let me take a stab at what is going on here:

When the selected area is deleted, Mozilla "forgets" the update, still thinking
that the next character is on the following line.  So, Mozilla decides to place
the caret there.  Unfortunately, there is no following line, so rather than it
showing up on the next line, it shows up on the current one.

If you go to the end of the line after this procedure, and press Enter, the
caret should jump down 2 lines!!!  I think it is somehow fixing itself, finally
realizing that it lost track of the line counts, and we get the line back here.
 I have reported this behavior before in bug 95056, but  hesitate to call this a
dupe.

Brent:  According to other comments in that bug, this is actually happening in
MailNews component too.  Not happening to me, though.

Comment 7

[Brent]

Norton:  I checked out your suggestion and found this problem isn't caused by
the cursor being on the last line.  Try the same steps except type in an
additional line (type in "four") in step 1.  Problem is still there.  Build
2001090408 in Windows 98 still has this problem.  On the end-of-text problem, I
filed bug 93549 which was declared a dupe of bug 88024.

Comment 8

[Grey Hodge (jX)]

WFM Win98.

Reporter: Feel free to reopen if you see this on new builds.

Comment 9

[sujay]

marking verified...reporter, REOPEN if you still see this...

Comment 10

[Brent]

Bug is still present in 0.9.4.  The text must be selected in just the "wrong"
way to make the bug occur.  Tried slightly different ways of selecting the text.
 In the steps above try these for step 2:

2.  Move the cursor to the end of "two".  Hit the End key.  Hold down on Shift
and hit Right Arrow 4 times.  "thr" (and the end-of-line of "two") should be
selected.

If the cursor is put at the end of "two" with the Right Arrow (and the Left
Arrow?), the problem does not happen:
2.  Move the cursor to the end of "two".  Hit Left Arrow.  Hit Right Arrow.
Hold down on Shift and hit Right Arrow 4 times.

The bug does not occur if the text is selected by starting at the 'r':
2.  Move the cursor between the 'r' and 'e' in "three".  Hold down on Shift and
press Left Arrow 4 times.

Comment 11

[Joe Francis]

what happens if you type at step 4 instead of arrowing?  Does the text end up in 
the correct place?

Comment 12

[Brent]

Tried some different step 4's.
If 4) Type a '2', then hit Right or Left Arrow, caret movement is correct.
  The '2' is in the correct place.
If 4) Type a '2', hit Backspace, then Right or Left Arrow, caret movement
  is wrong in the same way as original step 4.  The '2' appears in the
  correct place and the Backspace erases the '2'.
If 4) hit Backspace, then Right or Left Arrow, the 'o' in "two" is deleted
  and the caret movement is wrong.

After many repetitions of this test, and with enough text above the test text
to make scroll bars appear, I sometimes got a slightly different behaviour for
step 4:
The caret would not move the first time I hit Right Arrow.  The first Left Arrow
would move the caret between the 't' and the 'w' instead of the 'w' and the 'o'.
What it seems like is that the caret is displayed in the correct position,
between 'o' and 'e', but the arrow keys operate on the caret as if it was
between the 'w' and 'o'.  Thus, the appearance of "not moving" when Right Arrow
is hit and the caret display is updated.  Haven't found a reliable way to
reproduce this different behaviour.

Comment 13

[Joe Francis]

what happens if you type at step 4 instead of arrowing?  Does the text end up in 
the correct place?

Comment 14

[Joe Francis]

Brent answered "yes" to my question offline, so that means this is a selection 
bug.  Over to selection...

Comment 15

[mjudge]

I was juuust about to give this to joe.  I will put this in 9.9

Comment 16

[Shotaro Kamio]

I confirmed on 0.9.8/Linux.

When I use my patch for Bug 102220, this bug doesn't occur.
Can anyone check it ?

Comment 17

[Shotaro Kamio]

This bug seems to be fixed on 1.0RC1(2002041711)/Linux.

Comment 18

[Brent]

Have not been able to reproduce this bug in RC1, RC2, or RC3.  So I assume a fix
for another (perhaps bug 102220) also fixed this.  Should the status be changed
to FIXED, WORKSFORME, or something else, or not changed?  I can reopen if I see
it again.

Comment 19

[Terri Preston]

WFM using win XP trunk build 2002052908, 'cause of this and other comments
marking WFM, please reopen if you see this behavior again