Cursor not appearing in textarea after tabbing into it

VERIFIED FIXED in mozilla1.0

Status

()

Core
Editor
P3
normal
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Drew Taylor, Assigned: kinmoz)

Tracking

({topembed+})

Trunk
mozilla1.0
x86
Windows NT
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 RTM],custrtm-, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9+) Gecko/20020402
BuildID:    2002040203

For any form with a text area, if you tab into the textarea from another element
the cursor will not appear. I assume the cursor is moving within the element,
but it is not visible. A click at the end of any text in the textarea will make
the cursor display, and arrow key use will move the cursor correctly. I don't
believe this bug was in 0.9.8.

Reproducible: Always
Steps to Reproduce:
1. Visit any page w/ a form that has a textarea and 1 or more other elements.
2. Try to tab into the textarea from another element.
3. Cursor is not visible. Type or move cursor w/ arror keys and cursor appears.
->Composer
Assignee: attinasi → syd
Component: Layout → Editor: Composer
QA Contact: petersen → sujay
this is a duplicate
Assignee: syd → kin
Component: Editor: Composer → Editor: Core
Whiteboard: DUPEME
(Reporter)

Comment 3

16 years ago
Sorry for the duplicate. What bug number is this a duplicate for? I couldn't 
find anything that seemed to be the same bug.

Comment 4

16 years ago
Bug 130418 or 133304?

Comment 5

16 years ago
Created attachment 78175 [details]
Focus on the textfield and then press TAB. Cursor still invisible

Is this really a dupe? The bugs mentioned in comment 4 are both fixed and this
bug still appears.

Comment 6

16 years ago
Strange though, because this works sometimes, sometimes not. Using build
20020404 Windows 2000.

Comment 7

16 years ago
** this effects a TEXTAREA element only afaict **

I have build
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9+) Gecko/20020419

The cursor is still invisible when the focus changes via a tab or shift tab. If
I use JScript to call setfocus() on a node in the dom, cursor is fine.

If I tab, **** tab (cursor invisible) then do an alt-tab to a different
application and back again. Cursor is visible. 

This bug doesn't reproduce with INPUT type="text" but does reproduce with TEXTAREA.

If this bug really is a dup, could someone RESOLVE it dup with a bug number?

(Assignee)

Comment 8

16 years ago
The short version of the problem is that there was code added to 
nsEventStateManager::MoveCaretToFocus() which manipulates the document's 
selection *after* focus was already given to the textarea. This caused the 
caret's selection changed notification listener to be triggered, which turned 
off the caret, and then bailed because it noticed that the selection the caret 
was operating on, and the selection which changed were different.

My fix simply moves this check to above the code that turns off the selection, 
so that we can bail before we turn the wrong selection off.
(Assignee)

Comment 9

16 years ago
Created attachment 80471 [details] [diff] [review]
Patch Rev 1

The short version of the problem is that there was code added to
nsEventStateManager::MoveCaretToFocus() which manipulates the document's
selection *after* focus was already given to the textarea. This caused the
caret's selection changed notification listener to be triggered, which turned
off the caret, and then bail because it noticed that the selection the caret
was operating on, and the selection which changed were different.

My fix simply moves this check to the point above the code that turns off the
selection, so that we can bail before we turn the wrong selection off.
(Assignee)

Updated

16 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1, topembed
Priority: -- → P3
Whiteboard: DUPEME → FIX IN HAND, need r=, sr=, a=
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 10

16 years ago
Cc'ing some editor folks for reviews.
(Assignee)

Comment 11

16 years ago
Created attachment 80668 [details] [diff] [review]
Patch Rev 1.1

Heh, was so focused on moving the selection check that I didn't notice it left
|if(mVisible)| blocks next to each other, which akkana pointed out. duh.

Added comments so that it's easier for others to see what's really going on.
Attachment #80471 - Attachment is obsolete: true

Comment 12

16 years ago
Comment on attachment 80668 [details] [diff] [review]
Patch Rev 1.1

r=akkana.
In case you care, the "it's" in the StopBlinking comment shouldn't have an
apostrophe. :-)
Attachment #80668 - Flags: review+
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: FIX IN HAND, need r=, sr=, a= → [adt2] FIX IN HAND, need r=, sr=, a=
(Assignee)

Updated

16 years ago
Whiteboard: [adt2] FIX IN HAND, need r=, sr=, a= → [adt2] FIX IN HAND, need sr=, a=
(Assignee)

Comment 14

16 years ago
*** Bug 139581 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
Comment on attachment 80668 [details] [diff] [review]
Patch Rev 1.1

sr=attinasi
Attachment #80668 - Flags: superreview+
(Assignee)

Updated

16 years ago
Whiteboard: [adt2] FIX IN HAND, need sr=, a= → [adt2] FIX IN HAND, need a=
(Assignee)

Comment 16

16 years ago
Fix checked into TRUNK:

  mozilla/layout/base/src/nsCaret.cpp  revision 1.88

Will let this bake on the trunk for a few days before requesting adt/drivers 
approval for checkin on the MOZILLA_1_0_0_BRANCH.
Whiteboard: [adt2] FIX IN HAND, need a= → [adt2][FIXED_ON_TRUNK] need a=
(Assignee)

Comment 17

16 years ago
For those of you that are curious as to why this problem doesn't happen for 
textfields ... textfields really should suffer the same problem, but it just so 
happens that the range that nsEventStateManager::MoveCaretToFocus() builds up 
causes nsTypedSelection::selectFrames() to generate an extra paint invalidation 
because the start of the selection is in a frame that !canContainChildren. As we 
all know, textareas can have children so this extra paint invalidation does not 
happen.

In any case, when the paint request gets processed, the presshell turns the 
caret back on.

It seems strange that when tabbing into a textfield, MoveCaretToFocus() is 
setting a range to be collapsed at offset zero under an <input> that can't 
contain children.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 18

16 years ago
Drew, please verify this on the latest build....let us know if it is fixed for
you now....thanks.
Blocks: 132224
(Reporter)

Comment 19

16 years ago
Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0+) Gecko/20020429, I can
confirm that the bug is fixed for me. Thanks for tracking this down. 

Updated

16 years ago
Keywords: topembed → topembed+

Comment 20

16 years ago
Comment on attachment 80668 [details] [diff] [review]
Patch Rev 1.1

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #80668 - Flags: approval+

Comment 21

16 years ago
Adding adt1.0.0 to get on the adt's radar.
Keywords: adt1.0.0
Whiteboard: [adt2][FIXED_ON_TRUNK] need a= → [adt2][FIXED_ON_TRUNK] [Needs adt1.0.0+]

Comment 22

16 years ago
Let's get this one in after RC2. adt1.0.0- [adt2 RTM]
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [adt2][FIXED_ON_TRUNK] [Needs adt1.0.0+] → [adt2 RTM][FIXED_ON_TRUNK] [ETA 05/15]

Comment 23

16 years ago
Marking Verified per comment #19
Status: RESOLVED → VERIFIED

Updated

16 years ago
Keywords: adt1.0.0- → adt1.0.0

Comment 24

16 years ago
adding adt1.0.0+.  Please get drivers approval again since it's been more than 3
days and afterwards check into the Mozilla 1.0 branch.
Keywords: adt1.0.0 → adt1.0.0+

Comment 25

16 years ago
Adding custrtm-; no impact on customization.

Comment 26

16 years ago
changing to adt1.0.1+ for checkin to the 1.0 branch for the Mozilla1.0.1
milestone.  Please get drivers approval before checking in.
Keywords: adt1.0.0+ → adt1.0.1+

Updated

16 years ago
Whiteboard: [adt2 RTM][FIXED_ON_TRUNK] [ETA 05/15] → [adt2 RTM][FIXED_ON_TRUNK] [ETA 05/15],custrtm-
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0.1

Comment 27

16 years ago
re=a=chofmann 
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1"
keyword and add the "fixed1.0.1" keyword." in the comments.
Keywords: mozilla1.0.1 → mozilla1.0.1+
(Assignee)

Comment 28

16 years ago
Fix checked into the MOZILLA_1_0_BRANCH:

  mozilla/layout/base/src/nsCaret.cpp  revision 1.85.28.4
Keywords: fixed1.0.1
Whiteboard: [adt2 RTM][FIXED_ON_TRUNK] [ETA 05/15],custrtm- → [adt2 RTM],custrtm-
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0, mozilla1.0.1+

Comment 29

16 years ago
verified in 6/4 branch build.
Keywords: verified1.0.1

Updated

16 years ago
Keywords: fixed1.0.1
You need to log in before you can comment on or make changes to this bug.