65509 - Very slow javascript pulldown menu

Status: VERIFIED WORKSFORME

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

Description

[Mox Soini]

(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

Comment 1

[Mox Soini]

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

Comment 2

[Fabian Guisset]

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

Comment 3

[Fabian Guisset]

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.

Comment 4

[Mox Soini]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[HJ]

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

Comment 7

[Phil Schwartau]

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

Comment 8

[Phil Schwartau]

Attachment: Here is the "menus" Javascript file

Comment 9

[Phil Schwartau]

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)
}

Comment 10

[Phil Schwartau]

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

Comment 11

[Phil Schwartau]

Attachment: Here is the "objects" Javascript file

Comment 12

[Phil Schwartau]

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])
  }
} 

Comment 13

[Phil Schwartau]

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 -

Comment 14

[Johnny Stenback (:jst)]

Attachment: Quantify data that shows where we're spending most of the time here.

Comment 15

[Johnny Stenback (:jst)]

Attachment: objects.js

Comment 16

[Johnny Stenback (:jst)]

Attachment: allothers.js

Comment 17

[Johnny Stenback (:jst)]

Attachment: menus.js

Comment 18

[Johnny Stenback (:jst)]

Attachment: client.js

Comment 19

[Johnny Stenback (:jst)]

Attachment: Simplified testcase

Comment 20

[Johnny Stenback (:jst)]

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).

Comment 21

[buster]

hoping to address perf/footprint issues before moz1.0

Comment 22

[Marc Attinasi]

Please help us decode this script...

Comment 23

[Brian Rogers]

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

Comment 24

[James Green]

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?

Comment 25

[Johnny Stenback (:jst)]

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

Comment 26

[Phil Schwartau]

Attachment: Simplified testcase (this one should come up properly)

Comment 27

[basic]

Attachment: testcase where all js are in the same file

Comment 28

[Dan]

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!

Comment 29

[Mox Soini]

Attachment: This is heavily stripped down and renamed version of all the scripts

Comment 30

[Mox Soini]

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

Comment 31

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 32

[Dimitrios]

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

Comment 33

[basic]

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?

Comment 34

[Kevin McCluskey (gone)]

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 35

[Marc Attinasi]

Comment on attachment 22740 [details]
Simplified testcase

does not work

Comment 36

[Marc Attinasi]

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.

Comment 37

[Scott]

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.

Comment 38

[Mathew McBride]

*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)

Comment 39

[Corrado Berti]

*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.

Comment 40

[Markus Hübner]

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.

Comment 41

[José Jeria]

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%.

Comment 42

[Markus Hübner]

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

Comment 43

[Kevin McCluskey (gone)]

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.

Comment 44

[José Jeria]

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

Comment 45

[Markus Hübner]

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).

Comment 46

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 47

[José Jeria]

WFM too with build 2002121204, Windows 2000.

Comment 48

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 49

[Markus Hübner]

verified - trunk build 2002121108 on win-xp pro.