Closed Bug 21545 Opened 25 years ago Closed 25 years ago

Caret jumps back in text field sometimes

Categories

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

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: gerbilpower, Assigned: kinmoz)

References

Details

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**
Assignee: karnaze → buster
Reassigning to Steve.
Assignee: buster → kin
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.
Status: NEW → ASSIGNED
Target Milestone: M13
Accepting bug. I've seen the behavior that gerbilpower@yahoo.com 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 jfrancis@netscape.com Buster ... we should probably file new bugs for the ones you reported above.
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.
Depends on: 21029, 21346
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.
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.
Summary: Cursor jumps back in text field sometimes → Caret jumps back in text field sometimes
Changing summary from "Cursor" to "Caret"
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Updating QA contact.
QA Contact: ckritzer → vladimire
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.
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.