#822 closed defect (fixed)
rewrite dj_addNodeEvtHdlr to avoid direct assignment to window.onload
| Reported by: | jtoering | Owned by: | Tom Trenka |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Core | Version: | 0.3 |
| Keywords: | onload dj_addNodeEvtHdlr | Cc: | |
| Blocked By: | Blocking: |
Description
With the following simple html the alert that is launched during onload works correctly in both IE and firefox if dojo.js is not included. Once dojo.js is included the alert only gets triggered in FF and the onload never fires in IE.
I'm guessing that if I set the onload by attaching an event handler or by using dojo.addOnLoad then this would work but the larger project we are evaluating dojo for doesn't have the luxury of being in control over how the entire page is built. We largely end up being components that can be dropped into somebody elses pages. Obviously it would be bad if all of the sudden their body onloads don't work just because they dropped in something that directly or indirectly uses dojo.
Simple Example
<html>
<head>
<script language="JavaScript" src="/dojo-0.3.0/dojo.js"></script>
<script>
// If dojo.js is included then this will fire in Mozilla but not in IE
function doit()
{
alert('doing it!');
}
</script>
</head>
<body onload="doit();">
</body>
</html>
Change History (6)
comment:1 Changed 13 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 Changed 13 years ago by
Where exactly is it documented? And it seems more like dojo destroyed my onload handler than the other way around.
So you are basically saying that dojo can't be used in an existing webapp that already makes use of body onload without altering the webapp to register the onloads in a different fashion?
comment:3 Changed 13 years ago by
| Cc: | jim.toering@… removed |
|---|---|
| Component: | General → Core |
| Keywords: | dj_addNodeEvtHdlr added |
| Milestone: | 0.3.1 → 0.4 |
| Resolution: | invalid |
| severity: | critical → normal |
| Status: | closed → reopened |
| Summary: | including dojo.js is preventing body onload from firing in IE → rewrite dj_addNodeEvtHdlr to avoid direct assignment to window.onload |
With due respect, just because dojo is doing the right thing doesnt make this a real and very practical problem with lots and lots of common use cases. Its also solvable - by having dojo do the even "righter" thing - avoid direct assignment to window.onload in the first place.
I've found I have to consistently patch hostenv_browser.js to replace the dj_addNodeEvtHdlr with one that uses addEventListener / addEvent intead of the direct assignment. This sidesteps the body onload attribute problem (handlers registered by the 2 methods co-exist), and also works around any 3rd party's attempts to set window.onload.
Direct assignment has been nothing but trouble and the patch has stood for me. Even if the DOMContentLoaded approach is taken, relying on direct handler assignment to window.onload in any fashion (e.g for Safari?) is trouble.
One place where this was an issue for me was where some legacy script on the same page used a appendEventHandler kind of function, using the handler.toString() technique to wrap the existing window.onload handler in a new function. Stringifying the handler and "re-compiling" it back to a function with new Function(statements) caused broke closures in handlers added by dojo. (I dont get to fix this stuff, I have to work alongside it. )
comment:4 Changed 13 years ago by
| Owner: | changed from anonymous to Tom Trenka |
|---|---|
| Status: | reopened → new |
Assigning to ttrenka at his request
comment:5 Changed 13 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
this is the correct, documented behavior. You destroyed Dojo's onload handler. Not a bug.
Marking invalid.