Closed Bug 165130 Opened 18 years ago Closed 18 years ago

Text in input box flickers when changed rapidly by javascript (Moz1.1 only)

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: bugzilla, Assigned: kinmoz)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Open the testcase in Mozilla 1.1 and you see that the text in the input
box flickers. This doesn't happen in Mozilla 1.0.
Tested under Linux:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
text flickers
The testcase is a HTML page containing an image that gets reloaded  using
Javascript code. The code checks every 10ms if the images has finished loading
and if not, adds a dot to the input box.
WFM on 1.1/Win2K (no flickering).  Linux only?
Checked it and it's true, the flickering doesn't happen on Win32. 
Maybe it's really a Linux only problem.
I definitely see this....

Looks like 10ms is just less time than it takes us to reflow and paint that 
area...
Sounds like it might be related to bug 165032, which happened between moz1.1b
and moz1.1 timeframe.
Depends on: 165032
Boris: If you load the testcase and press "STOP", the loading stops but the
javascript code keeps running. Thus dots get continuously _added_ to the box. It
seems, that the _complete_ box gets redrawn. That may lead to the flickering (if
done too fast or your machine is too slow?).

John: I don't think that this bug is related to bug #165032 because the problem
here is "flickering output" and not a "slow output" (as reported in #165032.
Anyway, typing in an URL wfm on mac. Maybe I type too slow :-)

I checked this problem on an IMac and saw the flickering.
Who's gonna set this to confirmed now ? ;-)


"Related" does not mean the same problem, only the same cause.
QA Contact: petersen → amar
To kin to investigate.
Assignee: attinasi → kin
Status: UNCONFIRMED → NEW
Ever confirmed: true
I discussed this with some of the guys in layout. I think what we're going to do
is disable the async reflow/painting changes from bug 141900 in single line
textfields to try and minimize the exposure of this painting lag problem. The
async perf fixes are still needed by textareas to make them responsive when the
textarea contains lots of text.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
Blocks: 158782
Depends on: 141900
This may be bug and bug #155188 seem to be related. onload seems to stay in a
infinate loop when dynamic generation of content and this is much worse when it
is xul. A testcase is at 
http://stlouis-shopper.com/~jtjsoftware/kiosk/neko/slide_show.xul
This is working in mozilla -0.9.9, 1.0.0, 1.0.1
This is not working in mozilla-1.1, 1.2a
This may be bug and bug #155188 seem to be related. onload seems to stay in a
infinate loop when dynamic generation of content and this is much worse when it
is xul. A testcase is at 
http://stlouis-shopper.com/~jtjsoftware/kiosk/neko/slide_show.xul
This is working in mozilla -0.9.9, 1.0.0, 1.0.1
This is not working in mozilla-1.1, 1.2a
Blocks: 174823
This bug has been temporarily fixed on the TRUNK with the checkin of attachment
101640 [details] [diff] [review] from bug 141900 during the mozilla1.2beta milestone. It basically
disables the code which landed as part of attachment 87307 [details] [diff] [review] (async reflow and
painting for text widgets) until all issues blocking bug 174823 can be resolved.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.