Closed Bug 120475 Opened 23 years ago Closed 8 years ago

Browser lockup when visting URL with javascript enabled

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: lkolesza, Unassigned)

References

(
URL
)

Details

Attachments

(3 files)

Source of banner.shtml (as text)
3.58 KB, text/plain
Details
Stack traces from interrupting the page load on WinNT
7.90 KB, text/plain
Details
The document.written <IFRAME> (see remark 2, Comment#2)
512 bytes, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.7+) Gecko/20020116
BuildID:    2002011604



Reproducible: Always
Steps to Reproduce:
1. Go to http://www.jimamidon.com/affiliates-quick.html

Actual Results:  Browser becomes unresponsive, have to kill using Close Program

Expected Results:  Browser does not lockup.

If I disable javascript for Navigator in preferences, then browser does not lockup.

Locup also occurs with 0.9.7 and 0.9.6
Confirming with Mozilla trunk binaries Linux, WinNT, Mac9.1
OS: WinME ---> All.
Assignee: rogerl → khanson
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows ME → All
Hardware: PC → All
The site might create an infinite loop in the classic manner,
by defining an onerror handler which itself causes an error:


1) The HTML has an external JS file at
   http://www.clicks4u.com/signbanr.js


2) This JS file document.writes the following:

var code = '<iframe src="http://66.70.45.160/banner.shtml" width="468" 
height="60" border="0"><a href="http://66.70.12.120/cgi-bin/ads.cgi?zone=' + 
category + ';banner=NonSSI;page=' + sponsor + '"><img ';
code += 'src="http://66.70.12.120/cgi-bin/ads.cgi?zone=' + category + ';page=' + 
sponsor;
code += '" width="468" height="60" border="0"></a></iframe>';


3) On page load, we see this error in the debug console:

Error: document.all is not a function
Source File: http://66.70.45.160/banner.shtml  <<<<<<<<<<<<< see 2) above
Line: 147


4) From http://66.70.45.160/banner.shtml : 

<BODY BGCOLOR=#000060 etc.
      ONKEYPRESS="gotkey()" 
      ONLOAD="flipon()">

<div id="banner1" style="position:absolute;width:468;height:60;zIndex:99">
<table cellspacing=0 cellpadding=0 border="0" valign="center">
<tr><td valign="center" bgcolor="#000060" height="60">
<a id="link1" href="http://www.clicks4u.com/executive.shtml" 
onClick="gotclick()">

<img id="image1" src="http://www.clicks4u.com/images/subscribe.gif"
height="0" width="468" border="0"
onLoad="state(this,1)" onError="state(this,2)" onAbort="state(this,3)">

</a></td></tr></table></div>

<div id="banner0" style="position:absolute;width:468;height:60;zIndex:1">
<table cellspacing=0 cellpadding=0
   border="0" valign="center">
<tr><td valign="center" bgcolor="#000060" height="60">
<a id="link0" href="about:blank" onClick="gotclick()">

<img id="image0" height="0" width="468" border="0"
onLoad="state(this,1)"  onError="state(this,2)" onAbort="state(this,3)">

</a></td></tr>
</table></div></BODY></HTML>


5) Note the onError handler of the <img> elements: onError="state(this,2)"
 
function state(t,s)
{
  var lp = (t.id == 'image0')?0:1;
  if ((s > 1) && (lp == ((page + 1) & 1))) { prepnext(); }
  if (s == 1) { loaded[lp] = 1; }
}


6) One must check that we actually reach the line invoking prepnext().
If so, prepnext() contains document.all, which causes an error in Mozilla:

function prepnext()
{
  var nextpage = page + 1;
  var image = document.all('image' + (nextpage & 1));
  image.src = getsrc(nextpage);
  document.all('link' + (nextpage & 1)).href = geturl(nextpage);
}


7) This might cause (in Mozilla) an infinite loop of errors.
   The only question is, does an error inside an error handler for 
   an IMAGE element cause recursion, the way it would for the BODY element?

   The other issue is point 6) above: do we actually reach prepnext()?
   Can't use the JS Debugger on this, because that hangs along with Mozilla.
Note, too, the onLoad() handler for the <BODY> element:

<BODY BGCOLOR=#000060 etc. ONKEYPRESS="gotkey()" ONLOAD="flipon()">

where we have these functions:


function timer()
{
  if (tmrc > 0) 
  {
    tmrc--;
    if (tmrc == 0) { eval(tmrf); }
  }

  if ((stopfocus == 1) && (flipstep > 6)) 
  { 
    try {
      if (top.getfn() > 0)
      {
        if (loaded[(page + 1) & 1] == 0) { prepnext(); }

        flipon(); 
      } 
    } catch(e) { }
  }

  tmr = setTimeout('timer()', 50);
}

function setTimer(f,c)
{
  tmrf = f;
  tmrc = c;
}

function flipon()
{ 
   if (flipstep >= 6)
   {
     if (flipstep == 6)
     {
       prepnext();

       if (stopfocus == 0) { top.focus(); }
       
       flipstep++;

       setTimer('flipon();', 1200);

       return;
     }
     else if (loaded[(page + 1) & 1] > 0) 
     { 
       loaded[(page + 1) & 1] = 0; flipoff(); return; 
     }
   }
   else
   {
     var image = document.all('image' + (page & 1));

     flipstep++;

     image.height = flipstep * 10;
   }

   setTimer('flipon();', 1);
}

function flipoff()
{
   if (flipstep == 0)
   {
     var oldbanner = document.all('banner' + (page & 1));

     page++;

     var banner = document.all('banner' + (page & 1));

     oldbanner.style.zIndex = 1;
     banner.style.zIndex = 99;

     flipon();

     return;
   }

   flipstep--;

   var image = document.all('image' + (page & 1));

   if (image && (page > 0)) {image.height = flipstep * 10;}

   setTimer('flipoff()', 1);
}

timer();
Will have to look at this some more tomorrow.

In the meantime, I have discovered this: if I go to the parent URL, 
http://www.jimamidon.com/affiliates-quick.html, and save it LOCALLY,
Mozilla can load it fine: we're just missing the banner ads mid-way down the 
page, above the text "Get linked to THOUSANDS of sites instantly!"

From local HTML, this space is empty - that's probably the key.
At least I will be able to run the JS Debugger on the local copy.

cc'ing Boris in case he can figure this out before I can - 
I'm not sure what's going wrong here. Clearly the site needs to be
evangelized. Any use of document.all in Mozilla causes a run-time error,
and they use it everywhere.

However, I'm not certain that this is causing an infinite loop.
Clearly the onError handler of the two <IMG> elements contains the
document.all error. But I haven't shown that this onError handler
ever gets triggered. Furthermore, even if it does, I'm not sure if
the ensuing document.all error in the error handler function would
be registered as another error within the <IMG> element: thus causing
infinite recursion. Perhaps it's only registered in the <BODY> element.

I can't use the JS Debugger on the site itself, because Mozilla hangs
while loading the site. I also can't debug a local copy of the HTML,
because that DOES load in Mozilla! The only difference is that with
the local copy, we don't see the banner ad:
 
           http://66.70.12.120/cgi-bin/ads.cgi?zone

(See remark 2 in Comment#2 above)
I have extracted that document.written HTML from remark 2, Comment#2 above:

<SCRIPT>
var category = 1601;
var sponsor = 99105;
var sHTML = '';

sHTML += '<iframe src="http://66.70.45.160/banner.shtml" ';
sHTML += 'width="468" height="60" border="0">';
sHTML += '<a href="http://66.70.12.120/cgi-bin/ads.cgi?zone=' + category; 
sHTML += ';banner=NonSSI;page=' + sponsor;
sHTML += '"><img src="http://66.70.12.120/cgi-bin/ads.cgi?zone=' + category;
sHTML += ';page=' + sponsor;
sHTML += '" width="468" height="60" border="0"></a></iframe>';

document.write(sHTML);

</SCRIPT>


This successfully loads in IE6. It does not load successfully in Mozilla.
We only get a blue background, and it stops there. We see the same error
in the JavaScript Console as in remark 3), Comment#2 above.

I will attach this reduced example below -
I can't make any further headway; we need to debug the page load
at a lower level than the JS Debugger. Reassigning to Parser to 
find out if the site is feeding more and more HTML headers that
just don't stop in Mozilla - ?

cc'ing jband in case he can see immediately from the stack traces
attached above whether there is in fact an infinite event recursion
taking place. I see timer events there, but I'm not sure how to 
interperet them.
Assignee: khanson → harishd
Component: Javascript Engine → Parser
QA Contact: pschwartau → moied
One can also try the site http://66.70.45.160/banner.shtml directly.

Again, it loads fine in IE6, but not in Mozilla, presumably because
of the document.all error above (remark 3, Comment#2):

         Error: document.all is not a function
         Source File: http://66.70.45.160/banner.shtml
         Line: 147


However, Mozilla doesn't hang on this, so that seems to indicate
we do not get into an infinite error recursion within the onError
handlers of the <IMG> elements.
cc'ing jst; this is the bug I was describing. It includes <IMG> elements
with their own onError handlers. The onError handlers themselves cause an
error if they are ever called, because they use |document.all|. 

HOWEVER:

1. I'm not sure that the onError handlers are actually getting called.

2. I'm also not sure that a low element like an <IMG> would hear the 2nd,
   3rd, 4th... error events as they occur, causing infinite recursion.

3. The problem might actually lie in the timer() function (see Comment #3).
   This potentially can call prepnext(), which also uses document.all


I can't debug this with the JS Debugger (see Comment #7).
Ugh, looks like there's code on the page that sets an interval that ends up
executing JS code every 100ms, and it seems like that's starving the UI thread
completely. We don't lock up, we just get *really*, *really* busy processing
timers and we never get time to process UI messages (i.e. painting, mouse events
n' such...).

Over to Pavlov, we talked about re-introducing a low priority timer scheme which
were taken out when the new timer code landed.
Assignee: harishd → pavlov
Component: Parser → XPCOM
The problem is in
http://www.clicks4u.com/watermark.js

at the bottom, it calls setInterval(), which sucks because it really wants 
setTimeout, but that isn't what is killing us.

the code:
  if (navigator.appName == "Netscape") {
    if (navigator.appVersion.indexOf("6") == -1) {
      wm = document.jsbrand;
    }
  }

should be checking for nav4

it should be doing (indexOf("5") != -1) for NS6/moz and then using |wm = 
document.getElementById("jsbrand")|

What happens is it fails to set wm, then calls setInterval again.
So the first time through, we now have 2 repeating timers... then 4.. 8... 16...

Unless JS can detect this and stop it, there isn't much we can do.

This isn't a timer bug.  Handing back to jst
Assignee: pavlov → jst
Component: XPCOM → DOM Level 0
QA Contact: moied → desale
jst: quotas or sanity limits make some sense in the DOM level 0, the classic
codebase had 'em (I forget where, exactly, right now, but recall the concept
being applied).

bclary: do we need an evangelism bug too?

/be
I still think priority is a thread thing, not a timer thing.  The priority
parameter was spurious, it seemed to me (maybe not on some platforms), in the
old implementation.  Anyway, this bug isn't caused by lack of timer priorities,
it now seems.

/be
Evang bug 121565 created. If they do fix this script, they you may want to save
the offending page/script for reference purposes.
Severity = High [Since its locking up browser]
Visibility = Low [Gets one point of compatibility with other browsers. URL above 
works on NS4.x & IE.] 

Priority = Visibility * Severity

Priority = p3
Priority: -- → P3
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
might be fixed by bug 13350
WFM with recent Camino trunk build.  Tested with Camino trunk nightly 2006101622 (v1.2+) running under Mac OS 10.3.9.
Assignee: general → nobody
QA Contact: desale → general
WFM per previous coments
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: