R
Random
window.event always exists in IE, though outside of an event handler
(or recursively-called functions) its value is reported as null. It
doesn't seem possible to retrieve a reference to the window.event
object -- it always gives back a copy of itself (see code segment
below).
Based on this and several other quick-and-dirty experiments, it seems
most likely that IE has an internal class it uses to represent an
event, which it instantiates and exposes as window.event. When the
event's registered handler finishes, the value of window.event is
reverted to null (rather than a pointer or reference to an internal IE
object). The actual object is destroyed per normal garbage collection:
when its internal reference counter reaches 0.
It is also possible that it's not exposing an internal object but
instantiating a JavaScript object, but I doubt it-- trying to set
..srcElement to a string yields 'type mismatch', and error we're not
very used to seeing in JS.
Because of the garbage collection, it is possible to have two 'Event
objects' instantiated (by keeping at least one reference to an event
that was already processed), but I'm not certain that there is a way to
make two events _fire_ simultaneously. I've never tried on a
dual-processor machine. I did attempt in a very cursory fashion to make
IE process two events simultaneously, but it wouldn't do it. It wanted
to handle each sequentially.
Not necessarily.
An onClick for a submit button is processed in its entirety before IE
'bubbles' upward, instantiating a new Event object and referencing it
with window.event then calling the form's onClick. When the form's
onClick return()s, IE 'bubbles' again, instantiating a new Event
object, to the body. When bubbling has finished, it instantiates an
Event and calls the form's registered onSubmit handler.
In fact, I couldn't get IE to run any other code while a handler was
running, so I couldn't get a better look at some of the finer details
in question here.
Point being, only one value for window.event is ever required at any
given moment.
Code segment referenced above:
<html>
<script>
var x = window.event;
var y;
function onload() {
y = window.event;
alert( x );
setTimeout( 'alert(y)', 1000 );
setTimeout( 'alert(x)', 2000 );
setTimeout( 'alert(window.event == y)', 3000 );
}
</script>
<body onload=onload() />
</html>
(or recursively-called functions) its value is reported as null. It
doesn't seem possible to retrieve a reference to the window.event
object -- it always gives back a copy of itself (see code segment
below).
Based on this and several other quick-and-dirty experiments, it seems
most likely that IE has an internal class it uses to represent an
event, which it instantiates and exposes as window.event. When the
event's registered handler finishes, the value of window.event is
reverted to null (rather than a pointer or reference to an internal IE
object). The actual object is destroyed per normal garbage collection:
when its internal reference counter reaches 0.
It is also possible that it's not exposing an internal object but
instantiating a JavaScript object, but I doubt it-- trying to set
..srcElement to a string yields 'type mismatch', and error we're not
very used to seeing in JS.
Because of the garbage collection, it is possible to have two 'Event
objects' instantiated (by keeping at least one reference to an event
that was already processed), but I'm not certain that there is a way to
make two events _fire_ simultaneously. I've never tried on a
dual-processor machine. I did attempt in a very cursory fashion to make
IE process two events simultaneously, but it wouldn't do it. It wanted
to handle each sequentially.
It would mean that we have 2 global vars with the same name and
different values (nonsense).
Not necessarily.
An onClick for a submit button is processed in its entirety before IE
'bubbles' upward, instantiating a new Event object and referencing it
with window.event then calling the form's onClick. When the form's
onClick return()s, IE 'bubbles' again, instantiating a new Event
object, to the body. When bubbling has finished, it instantiates an
Event and calls the form's registered onSubmit handler.
In fact, I couldn't get IE to run any other code while a handler was
running, so I couldn't get a better look at some of the finer details
in question here.
Point being, only one value for window.event is ever required at any
given moment.
Code segment referenced above:
<html>
<script>
var x = window.event;
var y;
function onload() {
y = window.event;
alert( x );
setTimeout( 'alert(y)', 1000 );
setTimeout( 'alert(x)', 2000 );
setTimeout( 'alert(window.event == y)', 3000 );
}
</script>
<body onload=onload() />
</html>
believe
there is in Gecko-based browsers.
Should we say "There is an event dispatcher in all browsers that..."
This way we are escaping a confusion between the Event as a programming
term definition (like Function, Subroutine, Loop etc) and some real
entity.
before bubbling starts.
Don't agree. It is rather simple to recreate a situation when we are
handling several events at once (say drag and mousemove). It would mean
that we have 2 global vars with the same name and different values
(nonsense). Actually Microsoft says the same on their usual baby-talk:
"The event object is available only during an event-that is, you can
use it in event handlers but not in other code".
So the eventstamp "event" acts as private variable: generic to the
event handler and its inner functions.
Not a recommende wayouterFunction.arguments[0].someEventProperty.
Just thinking off a way to work with intrinsic event handler having
some arguments to pass to other function:
<div onclick="f1(arg0,arg1,arg3)"> - no problem with IE, but in FF arg0
must be sacrificed to event/event property. It is not very convenient
to reserve first argument in each function for e, just in case if it
will be called from an intrinsic event handler.
?