173944 - Visiting squabble.org uses all available CPU power

Status: RESOLVED DUPLICATE of bug 161633

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

Description

[Jason A.]

Quick summary
=============

Visit http://www.squabble.org and scroll down the page. The CPU usage increases
and by the time you're about 30% of the way down, it hits 100% [on my Pentium II
366 Mobile]. Leave the page and everything's back to normal.


Build Info
==========

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021009


Reproducible?
=============

Always.


Steps
=====

1] Open http://www.squabble.org

2] Scroll down the page. Notice CPU usage rises dramatically. Soon you'll hit 100%.

3] Close the page or leave it. Things are fine again.


Additional comments
===================

1] Works fine with Opera 6.05 [haven't tried IE as I don't use it online].

2] Phoenix [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
Gecko/20021010 Phoenix/0.3] exhibits the same behaviour.

3] Squabble.org's front page is dynamic, so it may not be the same all the time.

Comment 1

[Charles Capps]

I'm seeing this.. 2002091708 on a Win2k SP2 P3-600.

It seems to be the scrolling.  When I hit page bottom, CPU use rose from ~20 (at
the top) to ~80.  When I scrolled back up, CPU use was pegged at ~98.  

Comment 2

[Ronald Tilby]

Confirming.  Mozilla Nightly 2002100317 on Windows NT  Java Plugin 1.4.1
Load Page - CPU Utilization is normal
Page Down/Up - CPU Utilization still appears normal
DRAG Scroll Bar halfway down the page using the mouse - CPU Utilization climbs
to 99% and STAYS AT 99%.

Comment 3

[Mitch]

Must be only Windows specific. Same javaplugin version works fine with
Linux and mozilla cvs 20021011

Comment 4

[Jason A.]

Have narrowed it down to JavaScript.

Disable Javascript in navigator, reload the page. Everything should work fine
now. Except, of course, the toolbar on the upper right corner.

Visiting every other page with the toolbar on that site has the same effect.

Opera handles it fine.

IE: will someone please test this site on Internet Explorer? Thanks.

Comment 5

[Phil Schwartau]

This site uses the "DHTML Menu Builder" menu template from xFX software:

<!-- DHTML Menu Builder Loader Code START -->
<script language="JavaScript" type="text/javascript">
var navVer = navigator.appVersion;
if(navVer.substr(0,3) >= 4)
if((navigator.appName=="Netscape") && (parseInt(navigator.appVersion)==4))
  document.write('<'+'script language="JavaScript" type="text/javascript"                                             
                      src="/includes/menu/global/nsglobal.js"><\/script\>');
else
  document.write('<'+'script language="JavaScript" type="text/javascript"                                             
                      src="/includes/menu/global/ieglobal.js"><\/script\>');
</script>
<!-- DHTML Menu Builder Loader Code END -->


Note that in Mozilla, this loads the DHMTL Menu Builder code
from http://www.squabble.org/includes/menu/global/ieglobal.js

Note: this file is "obfuscated", in that it has no carriage returns.
You can see it best in Mozilla's JavaScript Debugger (Tools > 
Web Development > JavaScript Debugger) with "Pretty Print" activated.
This will at least make the function definitions readable -


The ieglobal.js file calls global_SetupToolbar() at the top. 
By stepping through this in the JavaScript Debugger, I found this
function stuck in a recursive loop, calling itself via setTimeout( , 10):

function global_SetupToolbar()
{
  if (!global_MenusReady)
  {
    window.setTimeout("global_SetupToolbar()", 10);  <<<-------------- HERE
    return false;
  }

                etc.
}


I don't know why |global_MenusReady| keeps evaluating to false.
This will require further debugging.

But this is a DOM issue, not a JS Engine issue. Furthermore, a 
quick examination of the DHMTL Menu Builder code in the file above
shows mostly DOM property/method access. I didn't find any pure
JavaScript performance issues (such as creation of large arrays).

Reassigning to DOM Level 0 -

Comment 6

[Phil Schwartau]

Note this is probably an Evangelism issue. Boris has analyzed other
sites using the DHTML Menu Builder template from xFX software, and
has found a grossly inefficient codebranch in their xrep() function;
a branch which only Mozilla seems to be directed into:

                 see bug 161633 comment 2
                 see bug 182081 comment 11

Comment 7

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 8

[Gérard Talbot]

squabble.org is now a javascript-less webpage.
http://www.squabble.org/includes/menu/global/ieglobal.js
leads to a "404 Not Found" page. 
After searching,
http://software.xfx.net/menu/iexpmenu.js
is the new file; it still has the browser detection script based on user agent
string matching and it now has the code

function SetupToolbar(fr)
{
(...)
if(!MenusReady){window.setTimeout("SetupToolbar()",10);return false;}
(...)
}

I don't know if the DHTML menu builder still creates the problem. I couldn't
verify that.

Comment 9

[Alvaro Munoz-Aycuens]

Worksforme on OS X with Firefox 0.9.3 and Mozilla 1.8.3a 2004083008

Tested on http://software.xfx.net/utilities/dmbuilderde/index.htm

cpu use values normal

Comment 10

[Gérard Talbot]

- www.squabble.org is now a javascript-less site.
- http://www.squabble.org/includes/menu/global/ieglobal.js
leads to a 404 not found page
- the script functions in
http://software.xfx.net/menu/iexpmenu.js
still rely on user agent string detection. function SetupToolbar() is no longer
in there.

http://software.xfx.net/utilities/dmbuilderde/index.htm
is a demo of the script functions based on user agent string detection. It
WORKSFORME. DHTML menus are still slow to be rendered. Mozilla 1.8a3 build
2004083008 under XP Pro SP2 here.

Resolving as a DUPLICATE of bug 161633 because of the poor browser detection in
use in 
http://software.xfx.net/menu/iexpmenu.js

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