388193 - caret of xul editboxes blinks faster when moving mouse around

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Xuefer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

i'm refering to the I cursor of a input text box, not mouse cursor
<input type="text"> or <textarea> works great in html document, which is my expected result
where the problem is the the interface (xul i guess) of tools->option, and any other extension dialog box.

Reproducible: Always

Steps to Reproduce:
a.1. open tools->optiontab, 
a.2. click mouse on homepage input box (the homepage url)
and/or
b.1. open tools->optiontab, 
b.2. click mouse on homepage input box (the homepage url)
b.3. move mouse over the input box again and again

Actual Results:  
suppose cursor blinking is N ms of hidden and N ms of display
a. the I cursor 0.01 second display ->  N ms hidden -> N ms display -> ...
b. the I cursor blinking like N ms hidden and 0.01 second showing, it's hardly visible

Expected Results:  
a. the I cursor N ms display -> N ms hidden -> ..
b. the I cursor do NOT blink but stay in "display" status

Comment 1

[Marco Bonardo [:mak]]

i don't see this problem... Does the same happen in safe mode?

Comment 2

[Xuefer]

yes, in safe mode. i have windows xp theme off btw

Comment 3

[Marco Bonardo [:mak]]

yes, i can reproduce that the blinkng cursor blinks faster (somewhat random) if you move the cursor on the dialog, this happens with xp theme on and off

i cannot reproduce on Trunk so it is probably been fixed there, could you try a nightly build please?

if this works on trunk please mark this as WORKSFORME, development is focused on Trunk, branch will receive only fix to major bugs, it's probably not worth fixing this

Comment 4

[Xuefer]

yeah, it's fixed in trunk which looks like a new ui engine completely. but it's still reproducable with 2.0.0.5 nightly build.

Comment 5

[Adam Guthrie]

If this is fixed on trunk, then I'm going to resolve this as WORKSFORME. Branch is only taking stability and security fixes right now, so there is little to no chance of this getting fixed on branch.

->WORKSFORME