(always reproducible) I'm using Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010112 and I've noticed that the javascript-enabled pages are sometimes very sluggish. The "test-case" for this is http://www.helsinginsanomat.fi where one can access the pulldown menus of the "always on top" menubar (gray colored). The menu seems to be written in javascript (only) and works smoothly with IE and NN, but with Mozilla it brings my 200Mhz pentium to knees for 3-5 seconds. I haven't noticed any build that would have fixed this one (haven't tested them all tho :) This could be related to bug 40988 or some others, but I couldn't really find a matching one... Thanks for the great browser ! Mox

*** Bug 65510 has been marked as a duplicate of this bug. ***

*** Bug 65510 has been marked as a duplicate of this bug. ***

What a mess! Why do they use document.write instead of a simple html layout? Anyway, I'm not seeing any popup on the page. The gray bar contains simple links that turn blue when mousing over them. The ad at the top of the page works fine too. Also mozilla doesn't freeze... So basically worksforme in mozilla0.7 win32 on a cyrix133.

Umm, there's some browser checks in the js-code, so it might behave differently if the version doesn't say m17 or m18... dunno. Anyways, the pulldown menus appear after a while if you hold the mouse cursor still over one of the links in the menu with the small black downwards arrow. There's also a yellow highlight-bar on the current selection, if you wait long enough...

Mozilla does not freeze on the page in question, but it _does_ take a long time to render the dropdown menus (it makes it eventually, but takes about 2-3 secs on a p3 733). adding perf keyword, OS -> all since I am seeing it on linux.

Well it seems that those very slow dropdown menus are caused by the repeated calls to setTimeout and clearTimeout.

Confirming with nightly binaries 20010116xx on WinNT and Linux. Browser, not engine --> DOM Level 0

Since the code in the menus.js file is so hard to read, here is a sample from it, with carriage returns added: function mss(v) { if(moi){clearTimeout(moi)} if (visa.length>0) { v0=visa[visa.length-1]; if (v!=v0){msh()} } ms(v) } function ms(v) { if (hands){pta()} aput(visa,v); vism=true; mt=O['menubar'].oGT()+20; v3=(v+'w'); v4=(v+'b'); n=eval('window.'+v); ml=parseInt(n.left); if(smt!="") { iwt=smt-gWST()+n.height; wh=gWH(); smt2=smt; while(iwt>wh) { smt2-=22; iwt-=22; }; if(smt!=smt2){mt=smt2} else{mt=smt}; ml=sml; smt="" } if(O[v3].oGT()!=mt) { O[v3].oST(mt); O[v3].oSL(ml); mt+=1; ml+=1; O[v4].oST(mt); O[v4].oSL(ml); v0=((v+'it')+1); i=1; while(O[v0]) { v1=((v+'ib')+i); v2=((v+'im')+i); O[v0].oST(mt); O[v0].oSL(ml); O[v1].oST(mt); O[v1].oSL(ml); O[v2].oST(mt); O[v2].oSL(ml); i+=1; mt+=22; v0=((v+'it')+i); } } str="ms2('"+v+"','"+v3+"','"+v4+"')"; moi2=setTimeout(str,200) }

The array "O" seems to be created inside functions in the "objects.js" file. I will attach this file below -

Since the code in the objects.js file is so hard to read, here is a sample from it, with carriage returns added: function makeObjects() { if(is_nav4){lNO()} else if(is_ie4){lIO()} else{lDO()} } function lDO() { E=document.getElementsByTagName("DIV"); O=new Array(); for(i=0;i<E.length;i++) { var v=E[i]; O[v.id]=new domO(v,i) } } function lNO() { O=new Array(); for(i=0;i<document.layers.length;i++) { O[document.layers[i].name]=new navO(document.layers[i]); for(j=0;j<document.layers[i].document.layers.length;j++) { O[document.layers[i].document.layers[j].name]=new navO(document.layers[i].document.layers[j]); for(k=0;k<document.layers[i].document.layers[j].document.layers.length;k++) { O[document.layers[i].document.layers[j].document.layers[k].name]=new navO(document.layers[i].document.layers[j].document.layers[k]) } } } } function lIO() { E=document.all.tags("DIV"); O=new Array(); for(i=0;i<E.length;i++) { O[E[i].id]=new ieO(E[i]) } }

In both NN4.7 and IE4.7, the drop-down menus render quickly (split-second). In Mozilla, they take several seconds to appear. Method: mouse over the menu link and wait -

To reproduce this just click on the simplified testcase I just attached and mouse over one of the links. Looks like when opening/closing the menus most of the time is spent in reflow code, have a look at the quantify data I attached (scoped at PresShell::ProcessReflowCommands which is the method (+D) taking most of the time), the columns are "F+D %", "Time+D in us", "Calls", "Method name". Steve, this time it reallly looks like mostly reflow, and other layout related code, reassigning to you. Let me know if someone needs more data (collected on WinNT 4.0, 400MHz PII with a build from early last week, I think).

hoping to address perf/footprint issues before moz1.0

Please help us decode this script...

Another site with JavaScript that's slow on Mozilla is http://www.someplacesomewhere.com/ Probably the same bug.

jst: your simplified testcase (22740) renders a blank, grey, document for me. No text; clicking in the page reveals nothing. Could be an XPCDOM regression?

Not sure, the menus original page still work, could be a problem with my simplified testcase. Someone care to investigate?

Testing in 0.9.2 on linux: though the performance is still not nearly as fast as Internet Explorer or Opera, it's tolerable now. I wouldn't close the bug altogether, but it's definitely getting there!

I took the _basic's version of the testcase and heavily stripped down all the unnecessary code (it most likely doesn't work on NS4.x or IE anymore). So now it should be much more easier (and shorter) to look through. Also, I renamed most of the variables and functions (in english) & added tabs and returns so that you guys can get hunch of what is going on... Looks annoyingly complicated to me though. As for the performance, if one has a fast computer (say a 800Mhz PC) the delay is almost tolerable. However, with low end machines (200Mhz and below) the delay is very annoying (3-5 seconds). Note that the testcase shows only the menus, it doesn't show the yellow bar on selected menu item nor the sub-submenus which both are viewable from the original page at http://www.helsinginsanomat.fi

Build reassigning Buster's bugs to Marc.

Just compared Mozilla, NS4.7 and IE5.5 with http://www.helsinginsanomat.fi/ : - Mozilla and IE 5.5 are on speed parity, no doubt about it. - NS4.7 unable to correctly render the pull down menu (only the text is visible) build 0.9.5, Win98, K6-III/400, 192MB ram

the menus in the url seems to work great in build 2001102903 win32 (trunk) the testcase seems ok but hovering seems to make the menus disappear. Would someone test this on other platform/OS and maybe later builds?

I see that it is slower with N6.2 than I.E when popping up the windows. CPU also goes to 75%-100% as menu is displayed. IE the CPU goes to 28%.

Comment on attachment 22740 [details] Simplified testcase does not work

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.

Another site that has a slow menu in Mozilla but not IE: http://www.wrh.noaa.gov/ It's the drop-down menu under "Home" that seems to be the problem... it is extremely annoying and makes me open IE to check the weather to avoid slowdowns with every pageview on the site.

*resolved*, *assigned*, *worksforme*. Works in: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608 (SeaMonkey Mozilla 1.1Alpha)

*worksforme* Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020619 It seems ok now, at least on Win platform.

using trunk build 2002061908 on win-xp,1.1ghz,512ram what is okay is the pop-up speed, what is still very slow is the highlighting. so when moving with normal mouse speed down the menu-list the highlighting doesn't follow.

Better, but the URL in this bug is still much slower than IE and Netscape 4. Also the mouseover effect on Windows 2000 is way too slow. OK-ish on Mac OS 9. And the url mentioned in comment 23 is too slow and CPU usage goes up to 100%.

Think fixing bug 124683 and bug 75121 will provide a performance gain here.

WFM: Using 2002/6/26 1.0 branch build. on 750Mhz AMD running WinXP. The menus pop up quickly and the highlighting tracks nicely when moving the mouse over the menu list. Compared with IE 6 on the same machine it gives me equivalent performance.

For me its not smooth at all. Hovering the menuitems is really slow. takes time before it gets highlighted. Using build 20020924, Windows 2000, Pentium III, 500 Mhz

Also for me (trunk build 2002092404 on win-xp pro,GeForce2 Go @32Bit) this is very slow (Hovering the menuitems and menu items take time before they get highlighted).

WFM with Mozilla 2002121008, or I cant get steps to reproduce. It might be fixed in a trunk...

WFM too with build 2002121204, Windows 2000.

I checked on Linux RedHat with newest trunk. It works there quite fine. resolving as WFM

verified - trunk build 2002121108 on win-xp pro.