Closed Bug 19242 Opened 25 years ago Closed 24 years ago

caret crufts in text areas

Categories

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

defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: aagno, Assigned: sfraser_bugs)

References

()

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3-][p;4])

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.
Assignee: karnaze → buster
Reassigning to Steve.
Assignee: buster → jfrancis
Component: HTML Form Controls → Editor
OS: Windows NT → All
Hardware: PC → All
Summary: Text area and more carriage return weirdness → Text area and more carriage return weirdness w/ arrow keys
Target Milestone: M12
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.
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.
Assignee: jfrancis → mjudge
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.
Target Milestone: M12 → M13
moving to M13
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this has been fixed. havent resolved it yet sorry. please verify. as far as i can tell it is working properly.
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
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.
wieeerd cool. let me see what the heck is goin on.
Status: REOPENED → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
this is fixed now. retest example.
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.
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.
Status: RESOLVED → REOPENED
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
hmm joe told me this was fixed but i still reproduced this myself joe please give this a try
Assignee: mjudge → jfrancis
Status: REOPENED → NEW
setting to m16 by executive fiat.
Target Milestone: M13 → M16
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.
Status: NEW → ASSIGNED
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.
The part about backspace not working is likely bug 27959, which I fixed today.
QA Contact: cpratt → sujay
changing qa contact and asking Sujay to verify if this is still broken
Sujay can still reproduce it, so it is still valid but I am moving this over to m17
Target Milestone: M16 → M17
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
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.
Okay, it (the shadow caret) is still happening on the 2000050820 build, so I'll reopen the bug. Andrew.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
assigning to sfraser. Simon, just look at the end of this bug report: it's morphed into a caret turd problem.
Assignee: jfrancis → sfraser
Status: REOPENED → NEW
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.
update the summary adding keywords
Keywords: correctness, nsbeta3
Summary: Text area and more carriage return weirdness w/ arrow keys → caret crufts in text areas
Target Milestone: M17 → M18
Whiteboard: nsbeta3+
setting to nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard - tricky to get this working on all platforms. Low risk, but time consuming.
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p;4]
Can someone familiar with this bug take a look at bug 46850 and mark it a dup, if it is one? Thanks.
46850 may be a little different, so I'd like to keep both open.
Status: NEW → ASSIGNED
moving this to future and adding helpwanted Need to triage to get on the appropriate glidepath for pr3
Keywords: helpwanted
Whiteboard: [nsbeta3+][p;4] → [nsbeta3-][p;4]
Target Milestone: M18 → Future
This was probably fixed by recent caret checkins. Please test and reopen if necessary.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified in 9/14 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.