19242 - caret crufts in text areas

Status: VERIFIED FIXED

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

Description

[aagno]

I'm pretty sure that this is different from the other carriage return bug,
or maybe the fix didn't get into M11.  In any case, here's my report.  The
reproducible bugs were all done with a fresh mozilla browser (M11) in Win NT
SP = latest as of Nov 18,1999 - 1.

In a text area, try the following with a new browser:
Oh, and I always had to page down once, then clicked in the Description
text area once (which also moved the view of the page, shifting it
left so that the text area was close to the left margin--this may be a
bug too--it's pretty annoying, anyhow--may have something to do with the
sidebar being up).

type 'hello there'
type carriage returns until you get to the next line (this
should require two carriage returns).  Now press the left
arrow key and you'll notice some weird behaviour.  It may take
one or two strokes to see the cursor go anywhere.

If you press enter, then press left arrow once, then try to get to the
bottom line, you can't.

Selecting text also goes funny:
type 'hello there' followed by return
left arrow once
then try to select text.  You can't.

Other stuff:
type 'hello there' followed by return
left arrow once
backspace
The entire line disappears

type 'hello there' followed by return
left arrow twice
right arrow three times
backspace
The cursor moves to between the h and the e of hello.
If you just do the left arrow once, then right arrow three
times, then backspace, you'll leave behind a mark where the
cursor used to be.

If you mess around with return, in addition to backspace, left arrow,
right arrow, then you can get other things to happen, that don't seem
to be consistently reproducible, although it will happen if you fiddle
enough:

- backspace too much, and the cursor disappears.

Comment 1

[karnaze (gone)]

Reassigning to Steve.

Comment 2

[Kathleen :Brade]

I see this on Macintosh so changing Platform/OS to all.
Change to editor  since I can reproduce there.

This bug is specific to arrow key actions after pressing enter/return.  (It may
be a duplicate but it's a good test to keep around.

Reassign to jfrancis since he does the handling for return/enter.

Set to M12 (initial triage) since Joe has a big checkin coming and this fix may
be in there.

Comment 3

[Sean Richardson]

Agree that this looks like at least one new reproducible wrinkle on the
 <textarea>problems. Will test these procedures on WinNT once bug 16715
has been fixed.

Comment 4

[Joe Francis]

i'm reassignint to mike for now.  If it's true that you can no longer select
after arrowing around, that's a selection problem.

Comment 5

[rubydoo123]

moving to M13

Comment 6

[mjudge]

this has been fixed. havent resolved it yet sorry. please verify. as far as i
can tell it is working properly.

Comment 7

[aagno]

The exact sequences I mentioned have been fixed in M12.  However, I can still
get weird things to happen, but I've only found one thing that I can
consistently reproduce (I'll mention the other two later):
In this form (bugzilla for bug id = 19242), I scroll down to the Additional
Comments text area, then I do the following:
hello there
<enter>
<delete>
<backspace>
<enter>

The caret then moves to one line after the line it should be at.  I'm not sure
if it's a new bug or remnants of the original one I had listed, so I've left it
in this one.

As for the other two problems I've encountered with M12, they are similar to
the ones I had before.  Namely, when I hit <backspace>, the caret will sometimes
move to somewhere in the middle of the line that I'm typing (it happened as I
typed this, actually), and no characters will be deleted.

Finally, I can still get a 'caret shadow' happening--sometimes there will be
this thin caret where the real caret was a before I hit backspace to go up to
the previous line.

Unfortunately, I can't consistently reproduce these latter two bugs.

Andrew.

Comment 8

[aagno]

Okay, I've got a reproducible test case:

In the additional comments form of this page:
hello there
<enter>
<delete>
<backspace>
<enter>
hello there
<enter>
<delete>
<backspace>
<enter>
<backspace>
<backspace>
<backspace>

For me, this leaves the 'shadow caret', as well as doing the final backspace
incorrectly (moving the caret to between the l and the o and leaving the shadow
caret at the end of the second there).

And this was done with a new browser, and no mistakes in typing the sequence.

Andrew.

Comment 9

[mjudge]

wieeerd cool. let me see what the heck is goin on.

Comment 10

[mjudge]

this is fixed now. retest example.

Comment 11

[aagno]

Is this fixed in the nightly build?  I grabbed the one dated Sun Jan 09 9:44:00
and it doesn't seem to have been fixed in it.

Andrew.

Comment 12

[aagno]

This still isn't fixed in M13.  Now, when I do the most recently listed example,
I get the 'shadow caret', and I still get weird carriage returns after the
<delete>
<backspace>
If you try doing <enter> after the last 'hello there' a couple of times, it'll
skip a line, just as if you had done the <delete><backspace> sequence.

So I think this problem still exists.

Andrew.

Comment 13

[leger]

Clearing FIXED resolution due to reopen.

Comment 14

[mjudge]

hmm joe told me this was fixed but i still reproduced this myself joe please 
give this a try

Comment 15

[Joe Francis]

setting to m16 by executive fiat.

Comment 16

[Joe Francis]

i dont see the shadow caret in recent builds.  The only problem I see is that 
after doing fwd-delete/backspace, the next <enter> causes two blank lines ot be 
created.  I suspect that doing forward-delete when at the end of the document 
has some bad effects.  I'll fix any weirdness I find there and see what happens.

Comment 17

[Joseph Elwell]

This seems to have gotten worse in the winNT 2000021708 build. Didn't notice it
in yesterday's build. But currently, all I have to do to reproduce it is:
1)Load a bug.
2)Scroll down to the Additional Comments section
3)Type "asdf<ENTER>"
4)notice the shadow carat two a whole line down from where I expected it.
5)hit <BACKSPACE>
I can backspace all I want and nothing happens.
This problem goes away with some fudging - but a reload and I can repeat the
whole thing again.

Comment 18

[Joe Francis]

The part about backspace not working is likely bug 27959, which I fixed today.

Comment 19

[rubydoo123]

changing qa contact and asking Sujay to verify if this is still broken

Comment 20

[rubydoo123]

Sujay can still reproduce it, so it is still valid but I am moving this over to 
m17

Comment 21

[Joe Francis]

fixed

Comment 22

[aagno]

I can still get the shadow caret, along with one new wrinkle.  I won't reopen
the bug unless
it is still there tomorrow, as I'm not sure when the nightly builds get built,
and I'm seeing
this on 2000050715, which may or may not include the fix, given the time and
date of the
fixed comment.

To get the caret, I go to this bug page, scroll down (using a whell mouse) to
the Additional
Comments, then click once in it.  I then press <enter>, <up arrow>, <delete>, <
enter>.
This gives me a shadow caret.  I suspect that I will always get one if I press
delete enough
times to get to the end of the text, but I've only tested it on two different
number of lines.

The new wrinkle is that this occasionally seems to persist across browser close
and reopen.
By this I mean that when I click in the Additional Comments, I can see that the
real caret is
over the shadow caret, and pressing enter will reveal the shadow caret.

However, backspacing and arrowing and deleting all seem to leave the caret where you
expect, so this remaining thing is pretty minor.

Andrew.

Comment 23

[aagno]

Okay, it (the shadow caret) is still happening on the 2000050820 build, so I'll
reopen the bug.

Andrew.

Comment 24

[Joe Francis]

assigning to sfraser.  Simon, just look at the end of this bug report: it's 
morphed into a caret turd problem.

Comment 25

[[e-mail]]

I have added this comment here because it relates to arrow keys after Enter.
Sometimes after pressing Enter in a textarea, I can press down arrow to move
down another line, although any typing forces the caret back.
Unfortunately it's not reproducable. It may also relate to bug 38194.

Comment 26

[rubydoo123]

update the summary
adding keywords

Comment 27

[rubydoo123]

setting to nsbeta3+

Comment 28

[rubydoo123]

adding the brackets in the status 

Comment 29

[rubydoo123]

setting priority in status whiteboard - tricky to get this working on all 
platforms.  Low risk, but time consuming.

Comment 30

[Brian Ryner (not reading)]

Can someone familiar with this bug take a look at bug 46850 and mark it a dup,
if it is one?

Thanks.

Comment 31

[Simon Fraser [no longer active]]

46850 may be a little different, so I'd like to keep both open.

Comment 32

[rubydoo123]

moving this to future and adding helpwanted

Need to triage to get on the appropriate glidepath for pr3

Comment 33

[Simon Fraser [no longer active]]

This was probably fixed by recent caret checkins. Please test and reopen if 
necessary.

Comment 34

[sujay]

verified in 9/14 build.