78179 - mozilla hangs if Error Console is flooded with (strict) warnings

Status: RESOLVED WORKSFORME

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

Description

[Henrik Gemal]

I'm not sure if this is a bug in the javascript engine or the way we show stuff 
in the console. If you go to http://www.wocs.dk and hava javascript strict 
option on the console is flooded with these warnings:

JavaScript strict warning:
http://www.wocs.dk/ line 488: reference to undefined property document.all

and the result is that mozilla becomes unavailable.

I think Netscape 4.x had some "too many warnings/errors" thing...

build 20010429

Comment 1

[Phil Schwartau]

Confirming with build 2001050208 on Linux. Steps to reproduce: 


1. Before bringing up the browser, set the JavaScript strict option to true 
by doing this:
   a. Open mozilla/defaults/pref/all.js in a text editor
   b. Make sure you have this entry: pref("javascript.options.strict", true)
   c. Save all.js

2. Bring up Mozilla and load http://www.wocs.dk

3. In the debug console you get an infinite cycle of these JavaScript 
strict warnings:
            
 http://www.wocs.dk/  line 489: reference to undefined property document.all
 http://www.wocs.dk/  line 492: reference to undefined property document.all
 http://www.wocs.dk/  line 499: reference to undefined property document.all

 http://www.wocs.dk/  line 489: reference to undefined property document.all
 http://www.wocs.dk/  line 492: reference to undefined property document.all
 http://www.wocs.dk/  line 499: reference to undefined property document.all

                           etc.
                           etc.

4. The site never finishes loading...well, I stopped waiting, in any case -

Comment 2

[Phil Schwartau]

From the JavaScript at the site, we see the above line numbers
are from a recursive function:


function slideit()
{
 if (!document.images)
   return
 if (document.all)                       <<<<<<<<<<<<<<<<<<<<<<  LINE 489
   slide.filters.blendTrans.apply()
 document.images.slide.src=eval("image"+step+".src")
 if (document.all)                       <<<<<<<<<<<<<<<<<<<<<<  LINE 492
   slide.filters.blendTrans.play()
 whichimage=step
 if (step<number_of_images)
   step++
 else
   step=1
 if (document.all)                       <<<<<<<<<<<<<<<<<<<<<<  LINE 499
   setTimeout("slideit()",speed*1000+3000)
 else
   setTimeout("slideit()",speed*1000)
}

Comment 3

[Henrik Gemal]

please remember that this bug is not about the actual warnings/error at the 
site. It's more about perhaps mozilla should give up after reporting the same 
error more than 50 times...

Comment 4

[Phil Schwartau]

Attachment: Linux stack trace obtained when I interrupted the page load

Comment 5

[Phil Schwartau]

Not sure if the stack trace I've attached is actually precise. 
The browser is unresponsive at this point, and one has no idea
what is going on.

Reassigning to DOM Level 0 for consideration. It is my understanding
that it's up to the embedding of the JS Engine to decide what to do with
JS warnings, by using the branch callback function the Engine provides.

One thing that puzzles me, though: why doesn't the same infinite recursion
occur when the JavaScript strict option is set to false? In that case, the 
site loads fine. How is it that the warnings are affecting the codepath of 
execution? 

Comment 6

[Henrik Gemal]

the same is true if you go to:
http://bugzilla.mozilla.org/query.cgi

and have:
user_pref("javascript.options.strict", true);
in your prefs.js

Comment 7

[Johnny Stenback (:jst)]

Our target users don't have "javascript.options.strict" set to true...

Comment 8

[Henrik Gemal]

I know. I just think that Mozilla should freeze while writing load of info to 
the console. Couldn't we do some lazy writting or something so that Mozilla has 
top priority and the console low priority?

I tend to close Mozilla before the console has ended it's output becuase I think 
that Mozilla has crashed (freezed)

Comment 9

[Johnny Stenback (:jst)]

Sure, in due time, patches are, as always, welcome.

Comment 10

[Johnny Stenback (:jst)]

Future.

Comment 11

[Alex Vincent [:WeirdAl]]

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

Comment 12

[Phil Schwartau]

From the duplicate bug 100911:


------- Additional Comment #15 From Phil Schwartau 2001-11-14 09:18 -------

This warning stands out. It repeats ad infinitum in the JS Console:

      Warning: reference to undefined property document.all
      Line: 81
      Source File: http://wocs.com

This is caused by the code below: window.onerror is set to a function
which itself produces a JS-strict warning. This causes the infinite loop -

window.onerror=reapply;
function reapply()
{
  setTimeout("slideit()",2000)
  return true
}

function slideit()
{
  if (!document.images)
    return
  if (document.all)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< LINE 81
  slide.filters.blendTrans.apply()
  document.images.slide.src=eval("image"+step+".src")
  if (document.all)
    slide.filters.blendTrans.play()
    whichimage=step
      if (step<number_of_images)
      step++
  else
    step=1
  if (document.all)
    setTimeout("slideit()",speed*1000+3000)
  else
    setTimeout("slideit()",speed*1000)
}


So the question here is, what should the DOM do if window.onerror
is set to a function which itself causes an error? That is what's
causing the infinite loop in this bug -

Comment 13

[Prashant Desale]

Severity = MEDIUM [(1)Almost like crash since browser becomes unavailable, 
(2)No functional failure, (3)No Cosmetic failure]
Visibility = LOW [(1)Our target users don't have "javascript.options.strict" set 
to true. (2)Gets one point of compatibility with other browsers since it works 
on all other browsers. ]

Priority = Visibility * Severity

Priority = p4

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.

Comment 14

[Frankie]

I agree this is low priority, since very few people browse routinely with strict
warnings turned on. But severity could easily be considered critical, because
the hang is nearly unrecoverable.

Bug 81279 is probably a dupe of this (and this bug might belong in JS Console
rather than DOM Level0), but I don't feel qualified to make that call.

Comment 15

[Frankie]

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

Comment 16

[Frankie]

This bug is exacerbated by bug 104549, because the strict warning is repeated
approx 11-15x every time document.all is called in a script.

Comment 17

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 18

[Andrew Schultz]

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

Comment 19

[Henrik Gemal]

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

Comment 20

[Henrik Gemal]

http://www.kokkeleg.dk also kills the browser if you have turned strict warnings on

Comment 21

[Mathieu Parent]

Bug #256932 has been fixed : Add support for exposing elements by their id/name
in the global scope (for IE compat)

so "document.all" strict warnings doesn't persist.

Comment 22

[Colin S]

TinyMCE triggers this bug.
http://tinymce.moxiecode.com/example_full.php?example=true

Firefox will prompt with an "Unresponsive script" warning but choosing "Stop script" does not work unless you close the Javascript console before clicking it.

The only messages outputted to the Javascript console state that an anonymous function does not return a value.

Comment 23

[Steve Chapel]

I can't reproduce this problem with any of the web sites given with Firefox 3 beta 2 rc 1 on Windows XP. I have javascript.options.strict set to true, but I don't get any unresponsive script warning or hang. I have a fast computer, so maybe the unresponsiveness is happening too quickly for me to notice. Could someone attach a testcase that will reproduce this problem even on a fast computer?

Comment 24

[Andrew Schultz]

Attachment: updated testcase

if (document.all) no longer generates a warning.  Actually using an undefined property still generates a warning.  Another thing that have helps is that the error console stops adding errors after it has some number of them.

Loading this testcase, SeaMonkey remains usable and responsive.  So perhaps we can close this bug.

Comment 25

[Steve Chapel]

Firefox also remains responsive with the new testcase.