Closed Bug 311152 Opened 17 years ago Closed 17 years ago

Delay before blinking caret moves when clicking in bordered input boxes


(Firefox :: General, defect)

Windows XP
Not set





(Reporter: rlibiez, Assigned: roc)


(Keywords: fixed1.8, regression, testcase)


(2 files)

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

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.
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: My money's on bug 309099, but I could
be wrong.
Ever confirmed: true
Keywords: regression
Summary: Short but noticable delay clicking in bordered input boxes → Short but noticeable delay clicking in bordered input boxes
Version: unspecified → Trunk
Both trunk and branch regression. What is the right component for this?
Keywords: testcase
Also reproducible with SeaMonkey 1.0b/20051004 and SeaMonkey 1.1a/20051004.
Requesting blocking1.8rc1? for a fresh visible regression. Cursor appears in
text field after almost one second
Flags: blocking1.8rc1?
Summary: Short but noticeable delay clicking in bordered input boxes → Delay before blinking caret moves when clicking in bordered input boxes
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,

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*.
Attached patch fixSplinter Review
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.
Assignee: nobody → roc
Attachment #198662 - Flags: superreview?(dbaron)
Attachment #198662 - Flags: review?(mrbkap)
Comment on attachment 198662 [details] [diff] [review]

Attachment #198662 - Flags: review?(mrbkap) → review+
This would address a regression caused by a last minute bug we took for beta 2.
Plussing so we can discuss this further.
Flags: blocking1.8rc1? → blocking1.8rc1+
Whiteboard: [needs SR dbaron]
Attachment #198662 - Flags: superreview?(dbaron) → superreview+
checked in on trunk.
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [needs SR dbaron]
Comment on attachment 198662 [details] [diff] [review]

This fixes a serious regression that is present on branch. We really really
don't want to ship with this caret-delay bug.
Attachment #198662 - Flags: approval1.8rc1?
Attachment #198662 - Flags: approval1.8rc1? → approval1.8rc1+
Verified fixed using Win FF 1.5.
You need to log in before you can comment on or make changes to this bug.