386820 - Gmail , compose mail, cursor missing in textfield

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070400 Minefield/3.0a7pre ID:2007070400

repro:
Open FF
Open Gmail
Press compose Mail and place the cursor in the textfield

result:
No cursor visable

regressionwindow:
works in 20070703_0613_firefox-3.0a7pre.en-US.win32
fails in 20070703_0644_firefox-3.0a7pre.en-US.win32

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183468380&maxdate=1183470239
-> Bug 238987

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Cursor is visible when plaintext editing is used.

Comment 2

[Peter van der Woude [:Peter6]]

(In reply to comment #1)
> Cursor is visible when plaintext editing is used.
> 
Likewise when you reply a mail with rich formatting

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 270883 [details] [diff] [review]
possible

...patch.
But need to think a bit if this breaks something else.

Comment 5

[Magnus Melin [:mkmelin]]

No cursor in thunderbird compose window today...

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proposed patch

This should work for now. If bug 235441 gets fixed, one may need to
add a listener for bubbling phase to catch the case when
focus is dispatched to the editor's piTarget.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

The patch fixes Thunderbird too.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Checked in.

Comment 10

[Peter van der Woude [:Peter6]]

Thanks for the quick response and fix Olli

Comment 11

[Ruediger Lahl]

(In reply to comment #8)
> Checked in.

In my SM-Trunk-build 2007070505 the cursor only appears, when I click into the text. Without the click, the bug always exists.

Comment 12

[Joanmarie Diggs]

I'm seeing the same thing in Thunderbird message composition window.  And arrowing around doesn't move the caret once clicking as gotten it to appear.  This makes selecting text and editing challenging.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #12)
> And
> arrowing around doesn't move the caret once clicking as gotten it to 
> appear.  This makes selecting text and editing challenging.
> 

I see this too, but afaik that is an older regression, possibly from
contentEditable.
I'll look at the other cursor visibility problem.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #13)
> I'll look at the other cursor visibility problem.
> 
Actually, https://bugzilla.mozilla.org/show_bug.cgi?id=386872#c2
says that the visibility problem started 6-28, so that cursor visibility problem isn't the same as this one.
contentEditable was checked in 6-27
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-27&maxdate=2007-06-28&cvsroot=%2Fcvsroot
So, I'd say that cursor visibility problem is bug 386174.

The problem with arrow keys is bug 386189.

Comment 15

[Joseph Yadacus]

This problem still exists as of today. Is there some doubt?