104549 - Too many duplicate warnings in javascript console on referencing an undefined variable or object property with strict warnings enabled

Status: RESOLVED WORKSFORME

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

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Seen on Linux trunk 2001101212-

1. Ensure JS strict warnings are on
2. Clear JS Console
3. Click on the URL above

Expected results in the JS Console: 
Warning: reference to undefined property document.all

Actual:
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all
Warning: reference to undefined property document.all


It's always displayed 14X.  Doesn't matter which object you pass alert(); if the
property you passed is undefined, you get 14 warnings.

Comment 1

[Fabian Guisset]

Maybe I got the answer in the WDF-DOM mailing list. It appears we throw an alert
for each letter of the string
"[object Object]"
Any idea why people?

Comment 2

[John Morrison]

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

Comment 3

[John Morrison]

See also testcase for an HTML document
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=59023

We really are calling js_GetProperty 15 times, but only when strict mode is 
enabled (a "printf proof").

We get into some goofy state where js_GetPropery ultimately calls
NS_ScriptErrorReporter, which wants to fire an event which needs to
js_GetProperty again, which wants to call NS_ScriptErrorReporter
(or something like that).

Comment 4

[John Morrison]

Attachment: stack trace of reentrant code (methinks that's what it is)

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Not that it matters too much, but I count 13 each of blarfs and snarfs in jrgm's
testcase, and 14 alls from the URL.

Comment 6

[m_mozilla]

http://wickline.org/mozilla/2001120100/
another example case, originally for bug 113078

Comment 7

[Phil Schwartau]

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

Comment 8

[Alex Vincent [:WeirdAl]]

jrgm, if that's the case, why aren't we getting a crash or something like that
because of recursive function calls?  Why exactly 13 warnings for each error?

Comment 9

[Alex Vincent [:WeirdAl]]

Incidentally, this bug and bug 81279 combine to generate a sizable performance
hit.  The sooner we get either one of these two bugs fixed, the better.

Comment 10

[Fabian Guisset]

I think I already gave the reason in my comment #1, but I never got around to
figure out why it is doing that.

Comment 11

[Stuart Ballard]

In my experience, this error also shows up for XUL documents, and for *any*
"reference to undefined variable" error, which makes using the JS console for
debugging a bit annoying, especially if you're a novice js programmer who hits
this kind of warning often ;)

Changing the subject to include more search-friendly words - I almost gave up
and filed a dupe.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

sballard: when changing summaries on bugs that have been around a while, please
try not to remove any words from the original bug summary.  People who have
queried with certain words may now find their queries are turning up blank.

For example, I query on this bug with "Too Many Warnings" and you've just
removed that.  I have no objections to rewording or making additions to any
summary for clarity, but please keep as much of the original summary as possible
to prevent future lectures ;)

Comment 13

[Stuart Ballard]

Sorry! I should have thought of that. I was worried that the summary was getting
excessively long already and the words "too many" seemed redundant; didn't occur
to me that people might already know the bug by those words.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Phil Schwartau]

cc'ing Bob from the duplicate bug -

Comment 16

[Phil Schwartau]

Attachment: Reduced testcase; run with JS strict warnings turned on

Comment 17

[Stuart Ballard]

I'm not sure I'd call that "reduced" compared to the testcase that's already in
the URL of this bug :)

Comment 18

[Phil Schwartau]

Oops! Missed that.

Comment 19

[John Morrison]

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

Comment 20

[tato]

I think this bug is so heavy...
because many pages use "if(document.all),if(document.layer),etc... ".

When use these width setTimeout or setInterval, ...like freez. 

Comment 21

[Phil Schwartau]

Increasing severity to major. This hits anyone who is trying to 
debug their scripts via the JS Console. Also see Comment #20 -

Comment 22

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[zack-weg]

Shouldn't this have Component "JavaScript Console"? I searched before filing the
dupe, but couldn't imagine it would live in another component.

And FWIW, I'm getting exactly *12* warnings.

It may be of interest that this code:

<script>
  var x;
  self.undefinedProperty;
</script>

yields 11 warnings for "QueryInterface" + 1 warning for "undefinedProperty"
(current Linux nightly, not in 1.4). This is because of |var x| and has not this
special behavior when used in

  data:text/html,<script>var x; self.undefinedProperty;</script>

I will attach it as testcase.

Comment 25

[zack-weg]

Attachment: testcase as in comment 24

Comment 26

[zack-weg]

Hmm, the special behavior with QueryInterface does not show up in the testcase,
but it does when I view it as a local file.

Comment 27

[zack-weg]

Ignore comment 26. I tested with Mozilla 1.4 by accident.

Comment 28

[zack-weg]

http://lxr.mozilla.org/mozilla/source/dom/src/base/nsJSEnvironment.cpp#139 :

181         static PRInt32 errorDepth; // Recursion prevention
182         errorDepth++;
183 
184         nsCOMPtr<nsIPresContext> presContext;
185         docShell->GetPresContext(getter_AddRefs(presContext));
186 
187         if(presContext && errorDepth < 2) {
188           nsScriptErrorEvent errorevent;
189           errorevent.eventStructType = NS_EVENT;
190           errorevent.message = NS_SCRIPT_ERROR;
191 
192           errorevent.fileName = fileName.get();
193           errorevent.errorMsg = msg.get();
194           errorevent.lineNr = report ? report->lineno : 0;
195 
196           // HandleDOMEvent() must be synchronous for the recursion block
197           // (errorDepth) to work.
198           globalObject->HandleDOMEvent(presContext, &errorevent, nsnull,
199                                        NS_EVENT_FLAG_INIT, &status);
200         }
201 
202         errorDepth--;

Is this the problem? Is HandleDOMEvent() actually synchronous? Is a static
variable guaranteed to be 0 initially?

Comment 29

[Phil Schwartau]

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

Comment 30

[Brendan Eich [:brendan]]

> Is HandleDOMEvent() actually synchronous? Is a static variable guaranteed to be
> 0 initially?

Yes and yes.

/be

Comment 31

[Stefan Borggraefe]

WFM with a current nightly build.

See also http://bugzilla.mozilla.org/show_bug.cgi?id=220603#c22.

Comment 32

[Boris Zbarsky [:bzbarsky]]

This does indeed seem to be fixed by the bug 220603 changes....

Comment 33

[Rick Alther]

I no longer see the problem since using Mozilla 1.6.