21545 - Caret jumps back in text field sometimes

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Alex]

When typing in a large text field, such as the one at the bottom of
http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser, the cursor will
sometimes jump back a number of characters suddenly while in the middle of
typing.

Not sure what action causes this bug to suddenly occur so it may be difficult
to reproduce.

Build tested is 19991212**

Comment 1

[karnaze (gone)]

Reassigning to Steve.

Comment 2

[buster]

here are twi cases I found, though I don't know if they are the ones the
reporter meant.  They are both tough to reproduce.
A) odd scrolling
1) open a bugzilla report (http://bugzilla.mozilla.org/show_bug.cgi?id=21545 for
example)
2) type enough text into the Additional Comments field to make the box scroll
vertically, say 20 lines of text.  I did this by typing in a lot of text to
cause lines to wrap, not by hitting lots of returns.
3) place your caret in the middle of the text, say on line 10 of 20.
4) start typing more text
5) as you get to the right edge of the control with your typing, you'll see the
caret line-wrap to the next line, but the scrolling is very odd:  instead of
subsequent lines being pushed DOWN, the caret stays in the same relative postion
in the text control pushing previous lines UP.  This gives a very odd user
experience.  I got this to happen once, couldn't get it to happen again.

B) odd end-of-line cursor jumping
1) again, fill the text control so it scrolls vertically.
2) include the following three lines
111111111111111111111111 2222222222222222222222222222222
333333333333333333333333333333333333333333 444444444444444444
5555555555555555555555555555555 6666666666666666666666666
3) if you put the caret after the last '2' or '4' and type, the caret jumps
around quite a bit until the next line wrap.  This was also tough to reproduce,
maybe had to do with whether I kept my focus in the text control the *entire*
time (from inital typing to the point where I reproduce the problem)?  That is,
if I started typing, clicked on something else, then tried to reproduce the
problem, it would not reproduce.  Maybe the act of acquiring focus causes
something to reset itself properly?  Just a guess, evidence is shaky.

Assigning to Kin, since I think this is only true with gfx scrollbars turned on.
Again, evidence is shaky, but I couldn't get either effect with native scroll
bars.  That might be coincidental.  cc'ing evaughan.

Comment 3

[kinmoz]

Accepting bug.

I've seen the behavior that [e-mail] is reporting and it is hard to
reproduce. I see it sometimes when typing and then hitting backspace while at
the end of the document. After hitting backspace, the cursor is sometimes placed
in the middle of the line instead of being left at the end.

This might have to do with bad caret placement after a transaction.

Cc'ing [e-mail]

Buster ... we should probably file new bugs for the ones you reported above.

Comment 4

[Joe Francis]

I have a sneaking suspicion that this bug might be related to 21029.  I recommend
that bug be fixed first, and then check this one for reproducibility.

Comment 5

[kinmoz]

This bug depends on both 21029 and 21346.

21029, is just a caret rendering bug. The caret will draw in the wrong place,
but all input will be placed at the correct
place.nsQueryInterface::operator()(const nsID & {...}, void * * 0x0012de24) line
31 + 23 bytes
nsCOMPtr<nsIContent>::assign_from_helper(const nsCOMPtr_helper &
{...}, const nsID & {...}) line 768 + 18 bytes
nsCOMPtr<nsIContent>::nsCOMPtr<nsIContent>(const nsCOMPtr_helper & {...}) line
497
GlobalWindowImpl::GetPrivateParent(GlobalWindowImpl * const 0x04992098,
nsPIDOMWindow * * 0x0012df38) line 3586
nsXULCommandDispatcher::GetControllerForCommand(nsXULCommandDispatcher * const
0x02e94b20, const nsString & {...}, nsIController * * 0x0012e028) line 519
XULCommandDispatcherGetControllerForCommand(JSContext * 0x015fdcb0, JSObject *
0x023f90a0, unsigned int 1, long * 0x03df6638, long * 0x0012e0e4) line 437 + 23
bytes
js_Invoke(JSContext * 0x015fdcb0, unsigned int 1, unsigned int 0) line 665
+ 26 bytes
js_Interpret(JSContext * 0x015fdcb0, long * 0x0012e954) line 2226 +
15 bytes
js_Invoke(JSContext * 0x015fdcb0, unsigned int 1, unsigned int 0) line
681 + 13 bytes
js_Interpret(JSContext * 0x015fdcb0, long * 0x0012f180) line 2226
+ 15 bytes
js_Invoke(JSContext * 0x015fdcb0, unsigned int 1, unsigned int 2)
line 681 + 13 bytes
js_InternalCall(JSContext * 0x015fdcb0, JSObject *
0x023f90a8, long 37944696, unsigned int 1, long * 0x0012f304, long * 0x0012f2b0)
line 758 + 15 bytes
JS_CallFunctionValue(JSContext * 0x015fdcb0, JSObject *
0x023f90a8, long 37944696, unsigned int 1, long * 0x0012f304, long * 0x0012f2b0)
line 2752 + 29 bytes
nsJSContext::CallEventHandler(nsJSContext * const
0x02e00c60, void * 0x023f90a8, void * 0x0242fd78, unsigned int 1, void *
0x0012f304, int * 0x0012f300) line 560 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x042353c4) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x0306b210,
nsIDOMEvent * 0x042353c4, unsigned int 4) line 651 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02e96f10, nsEvent *
0x0012f7f8, nsIDOMEvent * * 0x0012f7c0, unsigned int 7, nsEventStatus *
0x0012fa74) line 791 + 25 bytes
nsXULElement::HandleDOMEvent(nsXULElement *
const 0x0306b340, nsIPresContext * 0x02e96f10, nsEvent * 0x0012f7f8, nsIDOMEvent
* * 0x0012f7c0, unsigned int 1, nsEventStatus * 0x0012fa74) line 2676
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x030da980, nsIPresContext * 0x02e96f10, nsMouseEvent * 0x0012fb68,
nsEventStatus * 0x0012fa74) line 1358 + 42 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x030da980,
nsIPresContext * 0x02e96f10, nsGUIEvent * 0x0012fb68, nsIFrame * 0x023bb3b8,
nsEventStatus * 0x0012fa74, nsIView * 0x02e96c70) line 551 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x02e96734, nsIView * 0x02e96c70,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 2657 + 43 bytes
nsView::HandleEvent(nsView * const 0x02e96c70, nsGUIEvent * 0x0012fb68, unsigned
int 28, nsEventStatus * 0x0012fa74, int & 0) line 841
nsViewManager::DispatchEvent(nsViewManager * const 0x02e96d00, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent *
0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x02e96b44,
nsGUIEvent * 0x0012fb68, nsEventStatus & nsEventStatus_eIgnore) line 421 + 10
bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 442
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3332 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000)
line 3550
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long
3539264, long * 0x0012fdc8) line 2632 + 24 bytes
nsWindow::WindowProc(HWND__ *
0x010c0456, unsigned int 514, unsigned int 0, long 3539264) line 608 + 27 bytes
USER32! 77e71250()
00360

21346, has to do with the editor methods and transaction not placing the caret
in the correct place after certain operations.

Comment 6

[kinmoz]

I'm not exactly sure how that stack trace got pasted into my previous message,
since it wasn't there when I typed in the description and pressed submit. I
guess it's another 5.0 bug.

Comment 7

[Kathleen :Brade]

Changing summary from "Cursor" to "Caret"

Comment 8

[kinmoz]

jfrancis fixed a bunch of caret placement bugs for bug #21346 and I fixed the
wrong offset value (bug #21029). Marking this bug fixed. Please reopen if you
can reproduce the problem.

Comment 9

[Vladimir Ermakov]

Updating QA contact.

Comment 10

[Vladimir Ermakov]

Havent seen anything like this happen... Marking Verified.
 Windows 98 build 2000-09-25-08-M18
 Linux RedHat6.2 build 2000-09-19-21-M18.