Opened 16 years ago

Closed 16 years ago

Last modified 15 years ago

#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:


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

<script language="JavaScript" src="/dojo-0.3.0/dojo.js"></script>	
   // If dojo.js is included then this will fire in Mozilla but not in IE  
   function doit()
      alert('doing it!');
<body onload="doit();">

Change History (6)

comment:1 Changed 16 years ago by alex

Resolution: invalid
Status: newclosed

this is the correct, documented behavior. You destroyed Dojo's onload handler. Not a bug.

Marking invalid.

comment:2 Changed 16 years ago by anonymous

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 16 years ago by sam foster

Cc: [email protected] removed
Component: GeneralCore
Keywords: dj_addNodeEvtHdlr added
Resolution: invalid
severity: criticalnormal
Status: closedreopened
Summary: including dojo.js is preventing body onload from firing in IErewrite 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 16 years ago by sam foster

Owner: changed from anonymous to Tom Trenka
Status: reopenednew

Assigning to ttrenka at his request

comment:5 Changed 16 years ago by Tom Trenka

Resolution: fixed
Status: newclosed

(In [5492]) Fixes #822; attach to onload only for supported browsers (as listed on the FAQ of Opera 8.5 is the only edge case that will run on window load, and is attached via addEventListener; there is no more direct attachment to window.onload.

comment:6 Changed 15 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.