odd event handler execution?

[jeffjeff]

hello,

can any one explain why, in ie7 at least, clicking on the area where a button is supposed to be before the page is rendered, causes the event handler to be triggered after the page has loaded fully - allowing forward referencing in the handler code?

I tested this with a page that loads a button first and then an image. when the page is loaded and rendered, it behaves as expected: pressing the button causes the image's size to change (forward referecing the image is fine, the dom has been constructed). however, on fast connections i notice an odd scenario. After the button has been parsed but before it is rendered and before the image is parsed, clicking the area where the button will be causes the event handler to trigger after the page has fully loaded (not synchronously) and so allows the forward reference!. on slower connections, where the page is partially rendered , pressing the button before the rest of the page has loaded (the image) causes the expected forward reference error.

immediately queued timeouts (settimeout(foo(),0)) work as expected during page load, i.e. no forward referencing is allowed on fast or slow connections.

any thoughts?

cheers,

dean.

[jeffjeff]

hello,

sorry to reply to my own message but. with further testing, it does appear that user input events (not 'internal' events like timeouts), on a connection of sufficient speed that means no progressive rendering occurs and where the page is still loading, 'accepts' the user input (even though there's nothing on the screen) but delays the event dispatch until after the page has loaded. not a huge deal, we're talking about some pretty quick mousework to click the screen whilst its still blank!

[hrcerqueira]

As a workaround, attach the events only after the window.onload. Usually a http request response as a "interactive" state, bofore the "finished", meaning that the page is not fully loaded but you can interact with it.