DOM ready, window.onload, etc.
in [JavaScript]
|
Prev: FAQ Topic - Why do I get permission denied when accessing a frame/window? (2009-12-27)
Next: Best Performance Javascript on IE6 for finding top and left using offsetTop and offsetLeft
From: Hans-Georg Michna on 4 Jan 2010 16:25 On Sun, 03 Jan 2010 22:27:11 -0800, Garrett Smith wrote: >function readyStateChangeHandler(ev) { > ev = ev || window.event; > if(oldready) { > oldready.call(this, ev); > } >} Thanks, but now I'm getting confused with the execution contexts. How does this relate to my code? Since I'm no longer using document.readyState, only window.onload, my code currently looks like this: // Keep preexisting handler and append own handler: var precedingOLHandler = window.onload; window.onload = function () { // Remove all handlers: window.onload = null; // Execute all handlers exactly once: if (precedingOLHandler) precedingOLHandler(); doTheActualWork(); } I remove all handlers after the event fired to suppress any repeat firing that some crazy browser might try. Thought it can't hurt. While we're at it, what's the likelihood of missing the window.onload event? What if some sloppily designed browser fires the event while putting off the JavaScript processing or for some reason forgets to fire it at all? Can we rely on such things never happening? Hans-Georg
From: Garrett Smith on 4 Jan 2010 17:42 Hans-Georg Michna wrote: > On Sun, 03 Jan 2010 22:27:11 -0800, Garrett Smith wrote: > >> function readyStateChangeHandler(ev) { >> ev = ev || window.event; >> if(oldready) { >> oldready.call(this, ev); >> } >> } > > Thanks, but now I'm getting confused with the execution > contexts. When the browser calls `readyStateChangeHandler`, what is the `this` value? What do Function.prototype.call/apply do with the first argument? How does this relate to my code? Since I'm no longer > using document.readyState, only window.onload, my code currently > looks like this: > > // Keep preexisting handler and append own handler: > var precedingOLHandler = window.onload; > window.onload = function () { > // Remove all handlers: > window.onload = null; > // Execute all handlers exactly once: > if (precedingOLHandler) precedingOLHandler(); > doTheActualWork(); > } > What is the base object for the function call `precedingOLHandler()`? What is the execution context when precedingOLHandler is called? (in ES3; ES5 in strict mode is another matter). > I remove all handlers after the event fired to suppress any > repeat firing that some crazy browser might try. Thought it > can't hurt. > The other event handlers were already removed. Setting onload to null there means the callback won't fire again. For example, if a load event is synthesized and dispatched to window using createEvent/initMouseEvent. > While we're at it, what's the likelihood of missing the > window.onload event? What if some sloppily designed browser > fires the event while putting off the JavaScript processing or > for some reason forgets to fire it at all? Can we rely on such > things never happening? > window.onload is reliable where js enabled in the browser. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 4 Jan 2010 19:14 Lasse Reichstein Nielsen wrote: > John G Harris <john(a)nospam.demon.co.uk> writes: > >> On Sun, 3 Jan 2010 at 22:27:11, in comp.lang.javascript, Garrett Smith >> wrote: >>> Hans-Georg Michna wrote: > >>> No, null is not an object; null is a primitive value. >> <snip> >> >> That's true now, but there are signs that it was different in the far >> distant past. It looks as though it was originally thought of as an >> object pointer that happens to have a null value, as in Java, C++, etc. > > Now you are guessing. > > Anyway, in Java, null is not an object either. It's an Object > Reference value, referring to no object, and there is a different null > value of each object type. > > In JavaScript, you don't have type requirements, so you just need one > null value, and it's still not an object - so it's a primitive value. > > Whether it's really necessary to have both null and undefined (and > not, e.g., just two names for the same value) is a different > discussion. > I guess that the idea was to allow people to write something that > looked like Java. :) > Either that or to provide some sort of mapping from Java null to something other than undefined. s = new java.util.Vector(1); s.setSize(10); s.elementAt(0); Expected result would be null. (that example will run in a java enabled browser; runs in Firebug) -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 4 Jan 2010 19:17 On Jan 4, 4:25 pm, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > On Sun, 3 Jan 2010 06:58:17 -0800 (PST), David Mark wrote: > >On Jan 3, 6:32 am, Hans-Georg Michna <hans- > >georgNoEmailPle...(a)michna.com> wrote: > >> On Fri, 01 Jan 2010 15:36:22 -0800, Garrett Smith wrote: > >> >Hans-Georg Michna wrote: > >> >>> The example code, the callback for document.onreadystatechange changes > >> >>> context from document to window. > >> >> Oops, didn't even notice. What's the simplest way to do it > >> >> better? How do you even know what the original context was? > > [Detailed explanations why another option does not work snipped] > > So what am I to do? I guess the context change does not matter, > as there is no good reason for the onload event handler to make > itself dependent on "this". Mine certainly doesn't. Exactly. It shouldn't be an issue.
From: John G Harris on 5 Jan 2010 15:14
On Mon, 4 Jan 2010 at 22:00:47, in comp.lang.javascript, Lasse Reichstein Nielsen wrote: >John G Harris <john(a)nospam.demon.co.uk> writes: > >> On Sun, 3 Jan 2010 at 22:27:11, in comp.lang.javascript, Garrett Smith >> wrote: >>>Hans-Georg Michna wrote: > >>>No, null is not an object; null is a primitive value. >> <snip> >> >> That's true now, but there are signs that it was different in the far >> distant past. It looks as though it was originally thought of as an >> object pointer that happens to have a null value, as in Java, C++, etc. > >Now you are guessing. Obviously. That's why I wrote 'It looks as though' ... . >Anyway, in Java, null is not an object either. It's an Object >Reference value, referring to no object, and there is a different null >value of each object type. > >In JavaScript, you don't have type requirements, so you just need one >null value, and it's still not an object - so it's a primitive value. That's why I wrote 'object pointer', alias pointer to object. An Object Pointer type can be defined to include a null value, or not, whichever is thought more desirable. Since ECMA 262 was put together it's been not. The fact that the language doesn't allow you to handle pointers directly may have influenced the final choice. >Whether it's really necessary to have both null and undefined (and >not, e.g., just two names for the same value) is a different >discussion. This is part of the evidence for suspecting that null was originally thought of as the null member of a pointer type. >I guess that the idea was to allow people to write something that >looked like Java. :) I suspect not. >> As a result some ancient parts of javascript still call it an object, >> and they are too ancient to be changed. Possibly it's sometimes >> implemented as an object pointer with a null value, but this is not >> visible from outside. > >Indeed. And it's a royal pain the the backside that (typeof o == >"object") doesn't guarantee that it's actually an object. This is the other part of the evidence. John -- John Harris |