418055 - Caret turd remains with caret browsing, clicking in input while caret was somewhere else

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Martijn Wargers (dead)]

See bug 394473, comment 21:
"
I'm seeing a caret **** remaining, when I have caret browsering enabled and I
click on a text input, while the caret was somewhere else in the document.
The regression range was between 2007-11-09 and 2007-11-13, I think it was
caused by this patch.
Does patch v3 address that issue? Or should I file a new bug? (I guess so).
"

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Testcase

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Patch v2 from bug 394473 caused this bug, if I back it out, the problem goes away.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ok, the problem is in nsTextEditorEventListener::Focus(). We turn off ignoreUserMofify before calling Caret::SetCaretDOMSelection(), but SetCaretDOMSelection() calls StopBlinking() & StartBlinking(). Stop blinking calls DrawCaret() in order to blank the old caret out, but that won't paint if ignoreUserMofify is false, so it won't erase the old caret.

The solution is to turn off ignoreUserMofify after calling SetCaretDOMSelection(), not before. I'll update my patch for 394473 to include this fix.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

This was fixed by patch for bug 394473.