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.

WFM Linux 1.1b

very fast for me (1 day old win32 build) -> GFX

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.

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.

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

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.

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

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

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