Closed
Bug 201828
Opened 22 years ago
Closed 21 years ago
<body onload="onload()"> causes crash due to infinite recursion [@ XPCWrappedNative::GetWrappedNativeOfJSObject][@ needsSecurityCheck][@ JS_GetClass][@ js_AllocRawStack]
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: rbiciste, Unassigned)
References
()
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401
Browser crashes after page is loaded. It's happening on MacOS X and Linux and
even in Phoenix or Camino. I've tried to view various properties and it was
crashing constantly.
Reproducible: Always
Steps to Reproduce:
1. copy and paste URL into browser.
2. wait until page fully loads.
3. Ooops. Your browser just crashed.
Actual Results:
Crash
Expected Results:
Keep running
Confirmed using FizzillaMach/2003-04-11-08-trunk. TalkBack doesn't run after
this crash, which occurs in XPCWrappedNative::GetWrappedNativeOfJSObject.
Reassigning to JavaScript Engine.
Assignee: other → rogerl
Status: UNCONFIRMED → NEW
Component: Layout → JavaScript Engine
Ever confirmed: true
Keywords: crash
QA Contact: ian → pschwartau
Summary: Browser crashes after page is loaded. → Browser crashes after page is loaded [@ XPCWrappedNative::GetWrappedNativeOfJSObject]
|
||
Comment 3•22 years ago
|
||
Confirming with a debug Mozilla build 2003-03-27 on WinNT.
OS: Mac --> All.
The crash is due to stack overflow. This is caused by an infinite
loop created by the <body> onload handler at the site:
<body onLoad="onload()">
function onload()
{
initAd();
MM_preloadImages('/images/main_list_on.gif','/images/main_help_on.gif',
'/images/main_search_on.gif','/images/main_fav_on.gif',
'/images/main_loan_on.gif');
}
It doesn't matter what the onload() function contains; Mozilla
doesn't even call it. Just try this reduced testcase:
<title>Testcase: bug 201828</title>
<script>
var N = 0;
function onload()
{
if (N < 3)
alert('In onload() handler');
N++;
}
</script>
<body onLoad="onload();">
</body>
In Mozilla, none of the alerts come up, showing our custom onload()
is never called. What must be happening is this: we are not allowing
developers to "shadow" the window.onload function. So calling "onload()"
in the <body> onload handler is really going to call the pre-defined
DOM window.onload(), which triggers the <body> onload handler, which
calls the pre-defined DOM window.onload()... and we get an infinite loop.
Reassigning to DOM Level 0 for further triage. It's strange, I do not
crash at the site or on the reduced testcase with a trunk 2003-04-04
build. But I do crash with other builds I have...
In the VC++ debugger I see the JS branch callback is a |DOMBranchCallback|:
branchCallback nsJSContext::DOMBranchCallback(JSContext *, JSScript *)
Note bug 77271, "Need to filter recursive events to prevent crashes"
Assignee: rogerl → dom_bugs
Component: JavaScript Engine → DOM Level 0
OS: MacOS X → All
QA Contact: pschwartau → ashishbhatt
Hardware: Macintosh → All
|
|
||
Comment 4•22 years ago
|
||
|
|
||
Comment 5•22 years ago
|
||
The "most-reduced" testcase consists of this:
<title>Testcase: bug 201828</title>
<body onLoad="onload();">
</body>
This crashes my debug Mozilla build 2003-03-27 on WinNT as above,
with stack overflow due to infinite recursion in window.onload().
However, my current WinNT binaries can load this testcase without
crashing! I simply get this error in the JavaScript Console:
Error: too much recursion
Greg, what happens if you try the reduced testcase in Fizzilla?
|
|
||
Comment 7•22 years ago
|
||
*** Bug 205599 has been marked as a duplicate of this bug. ***
|
|
||
Comment 8•22 years ago
|
||
cc'ing Chris from bug 205599, and re-summarizing this bug
so that it is easier to find -
Summary: Browser crashes after page is loaded [@ XPCWrappedNative::GetWrappedNativeOfJSObject] → <body onload="onload()"> causes crash due to infinite recursion
Adding crash point as well as those mentioned in bug 205599 to summary.
Summary: <body onload="onload()"> causes crash due to infinite recursion → <body onload="onload()"> causes crash due to infinite recursion [@ XPCWrappedNative::GetWrappedNativeOfJSObject][@ needsSecurityCheck][@ JS_GetClass]
|
||
Comment 10•21 years ago
|
||
*** Bug 216311 has been marked as a duplicate of this bug. ***
|
||
Comment 11•21 years ago
|
||
Isn't the problem here that "onload" evaluated in an event handler looks at the
"onload" property of the object first before looking at the window scope? Is
that not the way it works in IE?
|
||
Comment 12•21 years ago
|
||
bz: the target object for <body onload=...> is the window object, so there is no
other object. We should do what Nav2-4 did, which I believe was to die a death
by infinite recursion. Suggest evangelism here. If someone can produce a spec
for what IE does, I'll read it.
/be
|
|
||
Comment 13•21 years ago
|
||
Brendan, see comment 5. Perhaps we just need to adjust the recursion limit?
|
|
||
Comment 14•21 years ago
|
||
See bug 220408, which *really* ought to get fixed soon, to fix a bunch of dups.
Since comment 5 was written, Igor Bukanov has led the charge to add stack depth
limiting checks to the JS engine in a complete way, and all (crossed-fingers --
we may need more ad-hoc checks in native code outside the JS engine) that we
need now is for the DOM to use the JS_SetThreadStackLimit API (and use it well).
/be
|
||
Comment 15•21 years ago
|
||
*** Bug 235737 has been marked as a duplicate of this bug. ***
I have to agree with comment 11 here. Don't we have a concept of properties on
the windowobject that are 'shadowable', in other words that if you define a
local function/variable with the same name it shadows the property on the
window-object.
|
||
Comment 17•21 years ago
|
||
IE stack overflows as well with the testcase in attachment 120455 [details], but that
attachment isn't exactly the common case. The common case is to define a global
onload function, and then set the body's onload="onload();".
In that case, IE does "the right thing", or whatever you want to call it, by
doing what the developer "intended", in this case.
The biggest difference between IE and Mozilla is that in Mozilla, <body
onload="..."> registers an onload handler on the window, and sets window.onload
to be that anonymous function, and does nothing on the body element. When
Mozilla runs the onload handler, it runs window.onload, in the window's scope.
In IE, <body onload="..."> will set body.onload, as well as window.onload,
*unless* window.onload is already set (by script in the head of the page). When
it fires the onload handler, it calls document.body.onload, if it exists, excep
if window.onload was set *after* it saw the <body onload="..."> tag, in that
case it calls window.onload.
So, it seems like in IE there's only ever one onload handler, and it can be
either document.body.onload or window.onload. And when IE runs the onload
handler, it always runs in the "global" scope (or a scope that's not document or
document.body), but that scope is not window either (smells like IE's global
scope object, whatever that is), so calling onload() from within an onload
handler registerd through <body onload="..."> will call the global onload
handler, which if defined before the body tag was seen, will be !=
document.body.onload.
Wow, what a mess. We could pull someting like this off if we really cared, but
is it worth it? Bug 220408 will take care of the stack overflow, hopefully
people will then realize what's wrong and fix their code...
Wow! Yeah, lets not try to replicate that unless we really really have to. I
just figured that if it was as simple as a flag then we might as well do it.
|
||
Comment 19•21 years ago
|
||
Noted another crash point, js_AllocRawStack, using Camino 2004-04-01-08.
Summary: <body onload="onload()"> causes crash due to infinite recursion [@ XPCWrappedNative::GetWrappedNativeOfJSObject][@ needsSecurityCheck][@ JS_GetClass] → <body onload="onload()"> causes crash due to infinite recursion [@ XPCWrappedNative::GetWrappedNativeOfJSObject][@ needsSecurityCheck][@ JS_GetClass][@ js_AllocRawStack]
|
|
||
Comment 20•21 years ago
|
||
The crash should now be fxied (by bug 220408), marking the rest WONTFIX.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
|
|
||
Comment 21•20 years ago
|
||
*** Bug 283392 has been marked as a duplicate of this bug. ***
|
||
Comment 22•18 years ago
|
||
*** Bug 350445 has been marked as a duplicate of this bug. ***
|
||
Comment 23•18 years ago
|
||
*** Bug 351299 has been marked as a duplicate of this bug. ***
|
||
Updated•13 years ago
|
Crash Signature: [@ XPCWrappedNative::GetWrappedNativeOfJSObject]
[@ needsSecurityCheck]
[@ JS_GetClass]
[@ js_AllocRawStack]
You need to log in
before you can comment on or make changes to this bug.
Description
•