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

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Daniel Kabs, reporting bugs since 2002]

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

Comment 1

[Daniel Kabs, reporting bugs since 2002]

Attachment: HTML Page with javascript code that updates an input box.

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.

Comment 2

[Malcolm Rowe]

WFM on 1.1/Win2K (no flickering).  Linux only?

Comment 3

[Daniel Kabs, reporting bugs since 2002]

Checked it and it's true, the flickering doesn't happen on Win32. 
Maybe it's really a Linux only problem.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I definitely see this....

Looks like 10ms is just less time than it takes us to reflow and paint that 
area...

Comment 5

[John Keiser (jkeiser)]

Sounds like it might be related to bug 165032, which happened between moz1.1b
and moz1.1 timeframe.

Comment 6

[Daniel Kabs, reporting bugs since 2002]

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 ? ;-)

Comment 7

[John Keiser (jkeiser)]

"Related" does not mean the same problem, only the same cause.

Comment 8

[Boris Zbarsky [:bzbarsky]]

To kin to investigate.

Comment 9

[kinmoz]

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.

Comment 10

[massey]

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

Comment 11

[massey]

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

Comment 12

[kinmoz]

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.