From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; rv:0.9+) Gecko/20010503 BuildID: 0.8.1+ Goging to that page with any build 0.8.1+ (not tested with earlier) causes the browser to freeze for several seconds (22 on my P2-366) before becoming responsive again. They utilize pretty advanced JS techniques for dropdown menus, so that is my educated guess for the source of the problem. I might try to narrow it down, but the file is a bastard of 800 lines. #mozillazine channel confirms that this occurs on all platforms. Reproducible: Always Steps to Reproduce: 1. http://www.cplc.org/ Actual Results: Browser freezes over. Expected Results: Well, in my perfect little world it should do everything instanteniously. :)

Ackk! The URL in description should be http://www.cplc.com/. Not org. It is correct in the URL field.

Has anyone seen how IE handles this? Netscape4.7 and Konqueror are both sniffed out of the picture so that no menus appear. It may just be that it's a big nasty hairy script. At least the author is being standards-compliant! ;)

Confirming with build 2001042704 WinNT. The site takes about 22 seconds to load: 12 seconds for the basic page to appear 10 seconds to create the drop-down menu items via JavaScript graf@relhum.org: This site loads in IE the same way as in NN4.7 : the drop-down menus are not created. Therefore IE, like NN4.7, doesn't have a performance problem on it.

Load the reduced HTML testcase in Mozilla. You will see the top-level menu rendered right away. But then you see the CPU pegged at 100% for about 10 seconds as the drop-down menu items are created dynamically via JavaScript - Many warnings like this appear in the JavaScript Console: Warning: test for equality (==) mistyped as assignment (=)? Source File: file:///C:/WINNT/Profiles/pschwartau/Desktop/78826_XXX.html Line: 1054, Column: 93 Source Code: if (document.all.formelements[x].style.visibility = "visible")

Fixing the warnings, however, doesn't improve the performance. Also, that is strictly IE's code, so Mozilla doesn't execute it at all (since condition for document.all is negative).

The 2nd testcase takes roughly the same time to load, even with the JavaScript errors corrected. I will attach WinNT stack traces I obtained by interrupting the page load of the 2nd testcase in a debugger. I do not have Quantify, so I can't give a better analysis of exactly what takes so long -

Is this is a browser performance issue or a JS Engine performance issue? By looking at the stack traces, I'm going to say browser and reassign. Sending to DOM. jst will know better whether this is DOM, Layout, or JS Engine, etc. Please reassign back if this is JS Engine -

Looks like more of the style resolution perf. problems with dynamic pages. Over to attinasi.

A page with a very similar problem: http://www.ada.org/public/index.asp Same stuff -- drop-down menus.

Perf doesn't sound bad on my (admittedly speedy) athlon 1ghz with 256MB RAM. However ther is a little problem: After mousing over a menu item, the popup appears -- fine. Then I put my mouse on the popup to select a menu item, but the popup disappears. Am I just missing something?

Yep 20secs or more to start the page here on my P300. BTW, http://www.ada.org/public/index.asp does not exhibit the slow loading problem for me.

www.telusmobility.com displays the same type of problems as cplc.com, but the performance is much worse (takes approx. 10 seconds for the "Products and Services" menu to appear with CPU utilization at 100%) Not sure if the source of the problem is the same, but I didn't want to open a new bug for it. I'm using build 20010531 on Win2K on a Pentium III 450 Mhz

IE 5.5 on the Mac has the same performance problems (and it displays the menus) - in fact, we are a little bit faster (5 sec on my G4 with Mozilla, 6 sec with IE)! FWIW: On my Win2K machine I can see no difference in the performance before and after the recent style rule matching improvements. I certainly think it is worth investigating the performance problems, but this is not an rtm stopper so I'm setting the milestone to 1.0. I'll dig in with Quantify and see what we are doing.

marking as dup of bug 21762 as no specific problem is demonstrated in this bug. Please see my post in npm.dom for more information. *** This bug has been marked as a duplicate of 21762 ***