127534 - Hangs when viewing page

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P2)

Description

[Rogier van Dalen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

0.9.7 used to display http://62.250.148.203/wrvd/, though it was 20 times as
slow as IE5, using 100% CPU.
0.9.8 hangs using 100% CPU.

Reproducible: Always
Steps to Reproduce:
1. Start Task Manager for CPU use
2. Type in "http://62.250.148.203/wrvd/"
3. Use "End process" in Task Manager to close Mozilla

Actual Results:  Mozilla hangs at 100% CPU, while previous milestones rendered
it painfully slowly at 100% CPU.

Expected Results:  The page should have rendered correctly and quickly.

Presumably it's got to do something with DHTML failures. I used W3C DOM for the
page, I believe.

Comment 1

[Olivier Cahagne]

Render it (somewhat painfully but usable) with CPU at 90% using build 2002022308
on Win2k.

Comment 2

[Steve Simms]

Reproduced the bug using win2k 2002-03-19-03.  I was able to get the page to
load and display (still with 99% CPU usage and near-freezing) by removing a lot
of the CSS in the initial STYLE tag, which makes me think that the problem is
that the page is too complicated for Mozilla to handle on my CPU (laptop with
Celeron 600MHz).  Works fine in IE6, however.

Comment 3

[Steve Simms]

Please ignore the CSS-related observations in comment 2 -- they were symptoms;
this is the actual problem:

This definitely looks like a performance/CPU-sharing issue related to Math.random().

For those who haven't looked at the page using another browser, it contains
eight lines created by a stretched 1x1 GIF file that are in constant, random
motion.  Removing the lines causes the page to load more or less fine (there are
some other issues, but not related to this bug).

Changing "lineNum = 4;" to "lineNum = 2;" reduces the number of lines being
drawn and moved from 8 down to 4 (each "lineNum" apparently consists of a
horizontal and a vertical line), which Mozilla can handle (65-80% CPU usage).

Alternately, editing the function moveLineRandom as follows:
< newX = line.x + ran()*mX;
> newX = line.x;
and
< newY = line.y + ran()*mY;
> newY = line.y;

served to reduce the number of Math.random() calls (the function ran() basically
calls Math.random() with a multiplier), and allowed the page to work properly
(CPU usage at 0% when loaded).

For thoroughness, I tried removing the ran() function altogether and replacing
it with direct calls to Math.random(), but this made no difference (CPU usage
through the roof).

I suggest moving this bug from "Browser - General" to "JavaScript - Engine" and
changing its status from UNCONFIRMED to NEW.

Comment 4

[Steve Simms]

-> JavaScript Engine

confirmed

Comment 5

[Phil Schwartau]

cc'ing Boris on this. The analysis by Steve in Comment #3 is very thorough.
Yet I can't help but believe the cause is due to something in the browser.
After all, the site runs fine in NN4.7, and I'm not sure if Math functions
in JS Engine have changed since then in a way that would explain this.

I suspect some feedback loop that is growing out of control in Mozilla.
Don't have time to look at it right now, but in stepping through the 
code in the JS Debugger, no single step took very long to execute...

Comment 6

[Phil Schwartau]

Note: with my Linux build, the site moves very slowly (very poor performance),
but does not hang. With my WinNT build, the lines seem frozen in place.

Until, that is, you Alt+Tab to another application and back to Mozilla
a few times. Suddenly the lines will move for a bit, and then freeze.

Why would that happen if it were purely a JS Engine performance problem?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile of this page running for a bit

Comment 8

[Boris Zbarsky [:bzbarsky]]

Math.random() doesn't even enter the equation.  The only reason the perf got
better when you removed the ran() part is that the lines were no longer being
moved hence no reflow happened, hence no time got taken up.

ccing shaver and jesup because this is exactly the situation their patch deals
with -- lots of things being moved in a single setTimeout (the timout here is
70ms, btw -- that should be plenty of time for us to not freeze up).

As a further note, the timeout is 70ms. I tried a very rough test of how long we
actually take between the calls.  The values had two modes at 88ms and 103ms
with an average of 92ms.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, and over to layout for real.

Comment 10

[Markus Hübner]

using trunk build 2002050508 on win-xp the page works fine!
think this one can be marked fixed (129953 / 117061).

Comment 11

[Chris Petersen]

Marking works for me in the May 03 OS X build (2002-05-03-09).