161766 - This page's links, loading, and scrolling respond very slowly

Status: RESOLVED DUPLICATE of bug 120893

(Core :: DOM: Core & HTML, defect)

Description

[Robert N]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020730
BuildID:    2002073008

For some reason Mozilla responds very slowley when on www.stenterprise.com
anything you try to do there takes very long for a reaction when clicking on a
link or scrolling just visit the page and you will see.

Reproducible: Always
Steps to Reproduce:
1.Go to www.stenterprise.com
2.Try scrolling
3.Or click on a link to see the responce.

Actual Results:  Everything reacts very very slowley making it almost unusable.

Expected Results:  For the page to respond normally and scrolling not to take ages.

Comment 1

[beanladen]

WFM Linux 1.1b

Comment 2

[Matthias Versen [:Matti]]

very fast for me (1 day old win32 build)

-> GFX

Comment 3

[Robert N]

I'll update my build tonight and try again, I also found it very slow with
Internet Explorer and Netscape 7, but Chimera loads and responds faster but not
by much.... Could this possibly be because of a low speed machine? If so this is
the only website that responds like this.

Comment 4

[Greg K.]

Confirmed using FizzillaCFM/2002080508. The page took 16 seconds to load, and
mouse wheel scrolling is abysmally slow, though dragging the elevator results in
faster scrolling.

Fizzilla's performance has been craptacular in general for several days now. See
also bug 161481, comments 10 and 11.

Comment 5

[Simon Fraser [no longer active]]

Ack, this page locked up Mozilla for longer than I was willing to wait (on OS
X). It's dreadful.

Comment 6

[John Morrison]

Fascinating, Jim.

I think this may be pilot error (i.e., the author is doing something bogus). 
[I need to check this again, since this JS is written with no whitespace or 
linefeeds].

The problem is see is specifically:


window.onscroll = SetupToolbar;
function SetupToolbar() {
    // do a whole bunch of stuff, including get and set positions
    // which can result in reflows...
    // ... and then queue this function up again:
    if (/* test: is this mozilla/5.0? */) {
        window.setTimeout(SetupToolbar, 100);
    }
}


So any scroll event triggers an infinite series of expensive operations on the 
document, launching (at least) every 100msec.

However, I don't think we should invalid this yet, since I also noticed that
on win2k (and presumably other OS) we go through the roof on the heap during 
the page (i.e., I was seeing VM Size grow by 50MB, and then shrink back down
as the page loaded).

At any rate the perf issues seem all related to the DHTML menu in that page. If 
I remove that from a mirror copy of the page, I load the page in about a third 
of the current loadtime and scrolling speed is acceptable. [Note: I dispute the 
previous assessment that this is "very fast" on win32. It's not. At all].

-> DOM, at least for now.

Comment 7

[Greg K.]

Note that the page is horrifically invalid and unwell-formed, with massive table
errors.

Comment 8

[John Morrison]

> horrifically invalid and unwell-formed, with massive table errors

So, in other words, it looks like a typical real=world web page? Is that what
you are pointing out?

Comment 9

[Daniel Wang]

*** This bug has been marked as a duplicate of 120893 ***