311152 - Delay before blinking caret moves when clicking in bordered input boxes

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Roger Libiez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1

A small but noticeable delay in clicking on input boxes has come up somewhere
between the Oct 1 and Oct 4 builds. I don't remember exactly where. This has
happened on two completely different PCs, one I use at home, the other at work.
The delay is not preset using either IE6 or Opera 8.5. It has something to do
with the CSS that governs the layout. With styling disabled the clicks are
instantaneous.

Reproducible: Always

Steps to Reproduce:
1. Open testcase link
2. Click in the input boxes it displays
3. Observe the slight delay it will take to actually move the cursor to the new box

Actual Results:  
The cursor delays moving into the new input box most of the time.

Expected Results:  
The cursor should have jumped instantly to the new box.

Comment 1

[Roger Libiez]

Attachment: Testcase for input delay

Comment 2

[Adam Guthrie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004
Firefox/1.6a1 ID:2005100413

Confirming. This regressed sometime between 2005-09-28-08 and 2005-09-29-08 in
trunk. Check-ins: http://tinyurl.com/a36n4 My money's on bug 309099, but I could
be wrong.

Comment 3

[José Jeria]

Both trunk and branch regression. What is the right component for this?

Comment 4

[zug_treno]

Also reproducible with SeaMonkey 1.0b/20051004 and SeaMonkey 1.1a/20051004.

Comment 5

[José Jeria]

Requesting blocking1.8rc1? for a fresh visible regression. Cursor appears in
text field after almost one second

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We have a stack like this:

#3  0x0000002a990cdb0a in nsCaret::DrawCaret (this=0x10ba7a0) at nsCaret.cpp:939
#4  0x0000002a990cc5ca in nsCaret::StartBlinking (this=0x10ba7a0) at nsCaret.cpp:506
#5  0x0000002a990cba64 in nsCaret::SetCaretVisible (this=0x10ba7a0,
inMakeVisible=1) at nsCaret.cpp:243
#6  0x0000002a990fb85b in PresShell::SetCaretEnabled (this=0x10b8170,
aInEnable=1) at nsPresShell.cpp:3059
#7  0x0000002a991d9664 in nsTextInputSelectionImpl::SetCaretEnabled
(this=0x10ea9e0, enabled=1)
    at nsTextControlFrame.cpp:752
#8  0x0000002aa0020475 in nsTextEditorFocusListener::Focus (this=0x10d9370,
aEvent=0x11c0980)

Basically the problem is that this makes the caret visible before we have
changed caret's DOM selection to point to the newly focused text box. So we draw
the caret in the wrong place and it gets clipped or worse. It won't paint again
in the correct place until the timer has fired *twice*.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This fixes the problem by having changes to the DOM selection repaint the caret
in the new position, if necessary.

I'm SO looking forward to Blake's patch making all this go away.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 198662 [details] [diff] [review]
fix

r=mrbkap

Comment 9

[Scott MacGregor]

This would address a regression caused by a last minute bug we took for beta 2.
Plussing so we can discuss this further.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in on trunk.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 198662 [details] [diff] [review]
fix

This fixes a serious regression that is present on branch. We really really
don't want to ship with this caret-delay bug.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed on branch.

Comment 13

[Greg K.]

Verified fixed using Win FF 1.5.