141888 - Caret not displayed in composer with pages containing readonly or disabled text widgets

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Helmut Schellong]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OpenUNIX i386; en-US; rv:1.0rc1) Gecko/20020419
BuildID:    2002041915

http://www.schellong.de/index.htm --> Edit Page --> in Composer
the text cursor is invisible at all.

Reproducible: Always
Steps to Reproduce:
1. Load Page
2. Edit Page
3. Place the -invisible- Cursor

Actual Results:  Text cursor is invisible

Expected Results:  Text cursor is always visible

Comment 1

[sujay]

confirming....

Comment 2

[Stan Bubrouski]

I can confirm this.  I am experiencing this problem as well.  Sometimes the
cursor is restored, but then it disappears again once I start clicking on areas
or click on another tab, like the Source tab or something.  Not sure if that is
what triggers it, but it makes it real hard to use the editor since you don't
know for sure where you are typing stuff into until it shows up.  Using build
2002051608, have seen it on yesterday's 2002052108 build and the problem goes
back to at least April, maybe further.  OS is Win2k Professional all latest SPs,
Hotfixes, and Windows Updates.

Comment 3

[Stan Bubrouski]

I see this most on pages with forms, to me it seems like the cursor is perhaps
getting stuck inside an invisible object.  As I'm currently writing a web
interface to an app, most every page I make involves forms, and a majority of
the time I have this problem.  It affects every view except source editor. 
Please try to fix this, it is a major issue.

Comment 4

[Stan Bubrouski]

Ok, apparently moving the cursors brings back the mouse, probably 100% of the
time,  this may be a dup of bug 130971.

Comment 5

[Kai Lahmann (is there, where MNG is)]

*** Bug 148664 has been marked as a duplicate of this bug. ***

Comment 6

[Ralf Hauser]

Still happens in 2002070708 build for win2k: I can reproduce it when I
select/hilite multiple empty lines in the "HTML-Source" tab.

Comment 7

[Kathleen :Brade]

-->core based on comment 3
is this only broken on the trunk or is it also broken on the 1.0 branch builds?

Comment 8

[kinmoz]

Changing summary from:

  text caret invisible (doesn't blink)

To:

  Caret not displayed in composer with pages containing readonly or disabled
text widgets

Comment 9

[kinmoz]

Attachment: Test Case

Comment 10

[kinmoz]

It looks like this bug is also in Netscape 6.2. I think it has to do with the
fact that under the covers there is only one caret per pres-shell that is shared
with both the outer document and all text widgets on the page.

Comment 11

[mjudge]

we had an over agressive disabling of the caret.  We do not need to disable it. 
the caret will blink or not blink dependant on focus after the text control is 
created.

Comment 12

[mjudge]

Attachment: patch for layout\html\forms\src\nsTextControlFrame.cpp

fix and comment to stop disabling of caret.  Disabling had the adverse effect
of disabling the caret for the whole page not just the text control.

Comment 13

[jag (Peter Annema)]

Comment on attachment 94176 [details] [diff] [review]
patch for layout\html\forms\src\nsTextControlFrame.cpp

sr=jag

Comment 14

[Garrett Arch Blythe]

Comment on attachment 94176 [details] [diff] [review]
patch for layout\html\forms\src\nsTextControlFrame.cpp

r=blythe

Comment 15

[Simon Fraser [no longer active]]

Can we have a unified diff with some more context please?

Comment 16

[Kathleen :Brade]

Comment on attachment 94176 [details] [diff] [review]
patch for layout\html\forms\src\nsTextControlFrame.cpp

please fix typo for "disableing" and capitalize it:  Disabling

Comment 17

[mjudge]

Attachment: nsTextControlFrame.cpp

spelling error fix

Comment 18

[Kathleen :Brade]

Comment on attachment 94211 [details] [diff] [review]
nsTextControlFrame.cpp

please provide a diff with context (cvs diff -u4 nsTextControlFrame.cpp)

Comment 19

[mjudge]

Attachment: patch with more context

more context to diff

Comment 20

[Simon Fraser [no longer active]]

Comment on attachment 94232 [details] [diff] [review]
patch with more context

sr=sfraser

Comment 21

[mjudge]

Attachment: test html file with bogus form. test textareas/ input fields

test file

Comment 22

[Kathleen :Brade]

Comment on attachment 94232 [details] [diff] [review]
patch with more context

r=brade

Comment 23

[Charles Manske]

*** Bug 133121 has been marked as a duplicate of this bug. ***

Comment 24

[Charles Manske]

Note that you can also use the steps described in bug 133121 to test this,
since in that case a disabled input field in a dialog revealed this problem.

Comment 25

[mjudge]

checked into trunk

Comment 26

[mjudge]

marking fixed since its in the trunk

Comment 27

[sujay]

verified in 9/6 build