By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,652 Members | 1,441 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,652 IT Pros & Developers. It's quick & easy.

Why 'event' is not defined in Mozilla

P: n/a
Hi,

Can somebody explain, why in following code, i get "event not defined"
error

funcTest(sMenu)
{
doument.getElementById('id1').addEventListener('mo usedown', function(){
click(sMenu, event); }, false);
}
But at the same time code as following works just fine

<input type="text" name="gadgets" id="gadgets" size="2" value="0"
onchange="funcChg();"

onkeypress="return isNumberInput(this, event);" />

Thanks
Prabh

Nov 25 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
pr*******@gmail.com wrote:
Can somebody explain, why in following code, i get "event not defined"
error

funcTest(sMenu) ^^^^^^^^[1] {
doument.getElementById('id1').addEventListener('mo usedown', function(){ [2]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^[3][4] ^^^^^^^^^^^ click(sMenu, event); }, false); ^^^^^^^^^^^^^^^^^^^^^^[4] }
But at the same time code as following works just fine

<input type="text" name="gadgets" id="gadgets" size="2" value="0" ^^^^^^^^^^^[5] onchange="funcChg();" ^^^^^^^^^[6]
onkeypress="return isNumberInput(this, event);" />

^^^^^^^^^^^^^^[7] ^[8]
[1] There is no user-defined funcTest() method probably causing a
problem here as the reserved word `function' is missing for a
FunctionDeclaration or FunctionExpression.

[2] There is no `doument' reference in any known DOM and it is none
user-defined here.

[3] There is no element with ID `id1' here.

[4] You do not feature-test anything.

[5] `type="text"' is optional for `input' elements.

[6] There is no built-in funcChg() method and none user-defined here.

[7] There is no built-in isNumberInput() and none user-defined here.

[8] XHTML is not supported by Internet Explorer, and sending XHTML as
text/html to achieve non-achievable "HTML compatibility" according
to XHTML 1.0, Appendix C, is considered harmful.

<URL:http://jibbering.com/faq/#FAQ4_43>
<URL:http://www.pointedears.de/scripts/test/whatami>
<URL:http://hixie.ch/advocacy/xhtml>
<URL:http://validator.w3.org>
<URL:http://jibbering.com/faq/>
PointedEars
Nov 25 '05 #2

P: n/a
On 25/11/2005 13:55, pr*******@gmail.com wrote:
Can somebody explain, why in following code, i get "event not defined"
error
Thomas commented on many problems, though omitted the cause of this
specific issue. An oversight, probably.

[snip]
doument.getElementById('id1').addEventListener('mo usedown', function(){
click(sMenu, event); }, false);
The W3C event model, as implemented by Mozilla and others (excluding
IE), does not define a global event object. Instead, the object is
passed to listeners.

var element;

if(document.getElementById
&& (element = document.getElementById('id1'))
&& element.addEventListener)
{
element.addEventListener('mousedown', function(event) {
click(sMenu, event);
}, false);
}

Notice the addition of an argument in the function expression.

Presumably, click is a user-defined function.
But at the same time code as following works just fine
[snip]
onkeypress="return isNumberInput(this, event);" />


When a browser encounters intrinsic event attributes, the value of that
attribute effectively becomes the body of a function object created
internally by the browser.

In IE, this transformation is similar to:

element.onkeypress = function() {
return isNumberInput(this, event);
};

As it defines a global event object, the 'event' identifier will resolve
to that global property.

In browsers that implement the W3C event model, the transformation is
similar to the function expression I posted earlier:

element.onkeypress = function(event) {
return isNumberInput(this, event);
};

In this way, the two models are markedly different, but interoperable
(in this instance).

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Nov 25 '05 #3

P: n/a
pr*******@gmail.com wrote:
Hi,

Can somebody explain, why in following code, i get "event not defined"
error
Beside all the syntax problems I will try to explain what is the problem
you are having (I think).
<input type="text" name="gadgets" id="gadgets" size="2" value="0"
onchange="funcChg();"

onkeypress="return isNumberInput(this, event);" />
When you are in an event handler (such as onkeypress) there is an
implicit event object.
You can see it better in the next example

<script type="text/javascript">
function test1(event)
{
alert(event.target);
}
</script>
<button id="btn">Button</button>
<script type="text/javascript">
document.getElementById("btn").onclick = test1;
</script>

Mozilla (and other standards compliant browsers) passes an event object
as the first parameter even though you did not pass this parameter
yourself explicitly.
Internet Explorer doesn't do this. However it has access to a global
event object in the window object.
The code above will not work in Internet Explorer, because the event
parameter will be undefined.
Therefore to make it work in both Mozilla and IE you will often see code
like this:

function test1(event)
{
event = event || window.event;
alert(event.target);
}

which first sees if the event parameter is defined and if not it will
use the global event object.

funcTest(sMenu)
{
doument.getElementById('id1').addEventListener('mo usedown', function(){
click(sMenu, event); }, false);
}


In this example there simply is no event object in scope for Mozila.
Internet Explorer uses the global event object.
To make this work your could do something like this:

function funcTest(event, sMenu)
{
doument.getElementById('id1').addEventListener('mo usedown', function(){
click(sMenu, event); }, false);
}

And you have to pass the event object yourself when calling funcTest.
Nov 25 '05 #4

P: n/a
Michael Winter wrote:
On 25/11/2005 13:55, pr*******@gmail.com wrote:
Can somebody explain, why in following code, i get "event not defined"
error


Thomas commented on many problems, though omitted the cause of this
specific issue. An oversight, probably.


No, that was deliberate. The OP is complaining about non-working code,
and provides an example that he says is working. However, he is showing
neither syntactically, let alone semantically, correct code nor a working
example.

Your correct explanation is based on the kind assumption that he used
different and otherwise correct code.
PointedEars
Nov 25 '05 #5

P: n/a
Michael Winter wrote:
The W3C event model, as implemented by Mozilla and others (excluding
IE), does not define a global event object. Instead, the object is
passed to listeners.

var element;

if(document.getElementById
&& (element = document.getElementById('id1'))
&& element.addEventListener)
{
element.addEventListener('mousedown', function(event) {
click(sMenu, event);
}, false);
}

Notice the addition of an argument in the function expression.
I have not tested it but I do think this will break in IE. The
argument the event listener is called would be 'undefined' and
scoping would force a reference to `event' within the listener
to evaluate to the value of the named argument instead of the
global event object. CMIIW, but I think the argument must be
named different from `event', and then it should be

click(sMenu, event || differentNamedArgument);

or

click(sMenu, differentNamedArgument || event);
onkeypress="return isNumberInput(this, event);" />


When a browser encounters intrinsic event attributes, the value of that
attribute effectively becomes the body of a function object created
internally by the browser.

In IE, this transformation is similar to:

element.onkeypress = function() {
return isNumberInput(this, event);
};


It is so in _all_ UAs (I know of), because `event' is defined in intrinsic
event _handler_ attribute values for those UAs. There is no difference in
IE.
As it defines a global event object, the 'event' identifier will
resolve to that global property.
No, the reason is a different one. See above.
In browsers that implement the W3C event model, the transformation is
similar to the function expression I posted earlier:

element.onkeypress = function(event) {
return isNumberInput(this, event);
};


Very much "similar", indeed. See above.
PointedEars
Nov 25 '05 #6

P: n/a
On 25/11/2005 19:24, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
[snip]
var element;

if(document.getElementById
&& (element = document.getElementById('id1'))
&& element.addEventListener)
{
element.addEventListener('mousedown', function(event) {
click(sMenu, event);
}, false);
}
[snip]
I have not tested it but I do think this will break in IE.


It won't break, but it won't work either because IE doesn't implement
the addEventListener method, so the if condition will, eventually,
evaluate to false. I assumed that the OP realised this, so I didn't comment.

[snip]
In IE, this transformation is similar to:

element.onkeypress = function() {
return isNumberInput(this, event);
};


It is so in _all_ UAs (I know of), because `event' is defined in
intrinsic event _handler_ attribute values for those UAs. There is
no difference in IE.


There is. Microsoft have always described their event object as a
property of the global (or rather, window) object, though it is only
available when an event is in progress.

An example, though not necessarily a conclusive one, demonstrates that
IE produces a function wrapper like the one displayed above.

<button onclick="alert(this.onclick);">Click me!</button>

It should output:

function anonymous()
{
alert(this.onclick);
}

On the other hand, Mozilla and Opera output:

function onclick(event) {
alert(this.onclick);
}

(even though the latter also implements IE's event model). Furthermore,
Mozilla have documented this as its actual behaviour[1].
As it defines a global event object, the 'event' identifier will
resolve to that global property.


No, the reason is a different one. See above.


I think it will be difficult to prove through code precisely what IE's
behaviour is. Though,

window.event == event

will evaluate to false, so will

window.event == window.event

which is bizarre, to say the least. It's possible that IE modifies the
scope chain to include the event object somewhere between the global
object and the activation/variable object, but I doubt it.

[snip]

Mike
[1] <http://developer.mozilla.org/en/docs/DOM:element#Event_Handlers>

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Nov 25 '05 #7

P: n/a
Michael Winter wrote:
On 25/11/2005 19:24, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
var element;

if(document.getElementById
&& (element = document.getElementById('id1'))
&& element.addEventListener)
{
element.addEventListener('mousedown', function(event) {
click(sMenu, event);
}, false);
}
[snip]
I have not tested it but I do think this will break in IE.
It won't break, but it won't work either because IE doesn't implement
the addEventListener method,


True. For the time being :)
so the if condition will, eventually, evaluate to false. I assumed that
the OP realised this, so I didn't comment.
ACK
In IE, this transformation is similar to:

element.onkeypress = function() {
return isNumberInput(this, event);
};


It is so in _all_ UAs (I know of), because `event' is defined in
intrinsic event _handler_ attribute values for those UAs. There is
no difference in IE.


There is.


Maybe I did not make myself clear. In the above code, the `event' reference
is indeed IE specific. However, the above code is your transformation of

onkeypress="return isNumberInput(this, event);"

And that is, as is, fully cross-browser (across all event-handling HTML
UAs I know of, meaning being DOM Level 0). The `event' _there_ does _not_
refer to a global event object in IE (well, maybe it does indirectly, but
to think about that is futile).
On the other hand, Mozilla and Opera output:

function onclick(event) {
alert(this.onclick);
}

(even though the latter also implements IE's event model). Furthermore,
Mozilla have documented this as its actual behaviour[1].
So?
As it defines a global event object, the 'event' identifier will
resolve to that global property.


No, the reason is a different one. See above.


I think it will be difficult to prove through code precisely what IE's
behaviour is. Though,

window.event == event

will evaluate to false,


Indeed, as it should.
so will

window.event == window.event

which is bizarre, to say the least.


Indeed, it should not. Maybe because it is a host object.
PointedEars
Nov 25 '05 #8

P: n/a
On 25/11/2005 22:30, Thomas 'PointedEars' Lahn wrote:

[snip]
onkeypress="return isNumberInput(this, event);"
[snip]
The `event' _there_ does _not_ refer to a global event object in IE
Is that supposed to be a statement of fact,
(well, maybe it does indirectly, but to think about that is futile).


or a statement that, for all intents and purposes, may as well be
considered fact? I can accept the latter for the sake of simplicity, but
not the former unless you can prove otherwise.

[MLW:]
window.event == event

will evaluate to false,


Indeed, as it should.


Even if event is a property of an object in the scope chain other than
the global object, I would find it hard to believe that its value is a
reference to a separate object.

I maintain (unless someone proves to the contrary) that they are not
only references to the same object, but the same property and the result
of the comparison above is a symptom of the behaviour exhibited when
window.event is compared to itself.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Nov 25 '05 #9

P: n/a
Michael Winter wrote:
<snip>
I maintain (unless someone proves to the contrary) that
they are not only references to the same object, but the
same property and the result of the comparison above is a
symptom of the behaviour exhibited when window.event is
compared to itself.


I would put my money on this as well. However, an experiment to find out
where this 'event' property is located might be performed. Say you have
an intrinsic event handler on a form control, where IE will add the form
and the document to the scope chain (as I recall, and without going back
and finding the thread of scope augmentation tests that were done a few
years ago). If a property was added to any object on the scope chain
with the name 'even' that property would mask this questionable 'event'
property if it was on any object lower in the scope chain.

If the real event object can not be masked by such a property then it
must exist at the top of the scope chain (Activation/Variable object or
similar). On the other hand, if it turned out that the document was the
lowest object on the scope chain that masked the event object it might
be reasonable to conclude that the unqualified identifier - event - did
indeed refer to the property of the window/global object.

I might try this out tomorrow, though I expect to be beaten to posting
result by one of you :)

Richard.
Nov 26 '05 #10

P: n/a
Richard Cornford wrote:
Michael Winter wrote:
<snip>
I maintain (unless someone proves to the contrary) that
they are not only references to the same object, but the
same property ...
<snip> ... , an experiment to find out where this 'event'
property is located might be performed.

<snip>

Well, I gave in and dug out the scope chain testing script and added a
string expando to the document under the name 'event'. And as I
suspected such an expando does make the window.event object when the
unqualified identifier 'event' is used in the value of an intrinsic
event attribute. That suggests that on IE the unqualified identifier
'event' does indeed refer to the global event object, and their failure
to compare is an oddity allowed by host objects.

In case anyone is interested in seeing this for themselves here is the
code:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">

function setExpandos(){
document.event = 'string'; //try to mask the event.
setExs(window,0, 'global');
setExs(document,1, 'document');
setExOn(document.body,2, 'body');
}
function setExOn(obj, depth, data){
if(obj.nodeType == 1){
setExs(obj,depth, data);
//if(obj.onclick)obj.onclick = showExpandos;
var o = obj.children||obj.childNodes;
for(var c = 0;c < o.length;++c){
setExOn(o[c], (depth+1), (depth+1));
}
}
}
function setExs(obj,start, data){
for(var c = start;c < 10;++c){
obj['ex'+c] = data+((obj.nodeName)?(' '+obj.nodeName):'');
}
}
var res = [
'chain results > ',
'\nex0 = ','', //2
'\nex1 = ','', //4
'\nex2 = ','', //6
'\nex3 = ','', //8
'\nex4 = ','', //10
'\nex5 = ','', //12
'\nex6 = ','', //14
'\nex7 = ','', //16
'\nex8 = ','', //18
'\nex9 = ','', //20
'\ntypeof event = ','' //22
];
function showExpandos(){
var a = res;
a[2] = ex0;
a[4] = ex1;
a[6] = ex2;
a[8] = ex3;
a[10] = ex4;
a[12] = ex5;
a[14] = ex6;
a[16] = ex7;
a[18] = ex8;
a[20] = ex9;
alert(a.join(''));
return false;
}
</script>
</head>
<body onload="setExpandos();">
<div>
<form action="">
<div>
<p>
<input type="button" value="Form Button"
onclick="var a = res;a[2] = ex0;a[4] = ex1;
a[6] = ex2;a[8] = ex3;a[10] = ex4;
a[12] = ex5;a[14] = ex6;a[16] = ex7;
a[18] = ex8;a[20] = ex9;
a[22] = (typeof event);
alert(a.join(''));return false;">
</p>
</div>
</form>
<table>
<thead>
<tr><th><a href="#"
onclick="var a = res;a[2] = ex0;a[4] = ex1;
a[6] = ex2;a[8] = ex3;a[10] = ex4;
a[12] = ex5;a[14] = ex6;a[16] = ex7;
a[18] = ex8;a[20] = ex9;
a[22] = (typeof event);
alert(a.join(''));return false;">
thead</a></th></tr>
</thead>
<tbody>
<tr><td><span>
<a href="#"
onclick="var a = res;a[2] = ex0;a[4] = ex1;
a[6] = ex2;a[8] = ex3;a[10] = ex4;
a[12] = ex5;a[14] = ex6;a[16] = ex7;
a[18] = ex8;a[20] = ex9;
a[22] = (typeof event);
alert(a.join(''));return false;">
tbody</a></span></td></tr>
</tbody>
</table>
</div>
</body>
</html>

Richard.
Nov 26 '05 #11

P: n/a
I am going to assume that in funcTest you don't have a
var event
just sMenu is defined.

In the input element the browser will define event and pass it to the
isNumbersInput function.

Nov 26 '05 #12

P: n/a
On 26/11/2005 01:06, Richard Cornford wrote:
Richard Cornford wrote:
Michael Winter wrote:
I maintain (unless someone proves to the contrary) that they are
not only references to the same object, but the same property ...
... , an experiment to find out where this 'event' property is
located might be performed.


Well, I gave in


After only an hour? :P
and dug out the scope chain testing script and added a string expando
to the document under the name 'event'.
Well, it's very good of you to do it. I was going to leave it until a
more reasonable hour this morning.

[snip]
That suggests that on IE the unqualified identifier 'event' does
indeed refer to the global event object, and their failure to compare
is an oddity allowed by host objects.


Is it though? Surely two references to the same object, host object or
not, should still compare as equal? I realise that host objects aren't
governed by ECMA-262, but the equality operator is and it would seem
that that's decisive in this case.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Nov 26 '05 #13

P: n/a
On Sat, 26 Nov 2005 20:45:27 GMT, Michael Winter
<m.******@blueyonder.co.uk> wrote:
On 26/11/2005 01:06, Richard Cornford wrote:
That suggests that on IE the unqualified identifier 'event' does
indeed refer to the global event object, and their failure to compare
is an oddity allowed by host objects.


Is it though? Surely two references to the same object, host object or
not, should still compare as equal?


The host object could be a pointer to an object, two instances could
then be different pointers, even though they reference the same thing.

Jim.
Nov 26 '05 #14

P: n/a
Michael Winter wrote:
On 26/11/2005 01:06, Richard Cornford wrote:
Richard Cornford wrote:
Michael Winter wrote:
I maintain (unless someone proves to the contrary) that
they are not only references to the same object, but the
same property ...

... , an experiment to find out where this 'event'
property is located might be performed.
<snip> That suggests that on IE the unqualified identifier 'event'
does indeed refer to the global event object, and their
failure to compare is an oddity allowed by host objects.


Is it though? Surely two references to the same object, host
object or not, should still compare as equal? I realise that
host objects aren't governed by ECMA-262, but the equality
operator is and it would seem that that's decisive in this case.


If I had been more awake I might have put two and two together last
night and realised that this is not an issue with the comparison
operator, or an inability to compare the event objects. Neither would be
a satisfactory state of affairs, fortunately neither are explanations
for the phenomenon.

Various browsers have made properties available that when read return
unique objects each time they are read. This is likely to mean that
behind the scenes there is a 'getter' for the property that creates a
new object whenever a script reads the property. This appears to be the
case with the window.event property in IE.

Tests that would help decide whether this is the case might be;

1. Assigning a reference to an event object to a local variable and then
copying that reference to another local variable. Both local variables
must be references to the same object so if the object cannot be
compared with itself as true, or the comparison operator was not
functioning, then you might still get an equality result of false, but
you actually get true.

2. Create and assign a value to a new property of the event object
referred to by one of these two variables. Read the property back to see
if it was successfully assigned and then try to read the property from
the window.event object. Then re-confirm that the object referred to by
the variables still has the assigned property.

The second test successfully assigned the value to a property of the
event object referred to by the local variable, but that property was
subsequently missing from an object retrieved using the unqualified
Identifier - event -, while still being a property of the object
referred to by the local variable after is was found to be missing
from - event -. I would conclude that each read of the value of the
global event property within an event handler returns a reference to a
different (but otherwise identical) event object, and that is why they
do not compare as being the same object.

Test code:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
</head>
<body>
<div>
<form action="">
<div>
<p>
<input type="button" value="Form Button"
onclick="
var st = 'window.event == event -> '
st += (window.event == event);
st += '\nevent == event -> '+(event == event);
st += '\nwindow.event == window.event -> '
st += (window.event == window.event);
var e1 = event;
var e2 = e1;
st += '\ne1 == e2 -> '+(e1 == e2);
e1.expndo = 'hellow'
st += '\ne1.expndo -> '+(e1.expndo);
st += '\nevent.expndo -> '+(event.expndo);
st += '\ne1.expndo -> '+(e1.expndo);
st += '\ne2.expndo -> '+(e2.expndo);
alert(st);
">
</p>
</div>
</form>
</div>
</body>
</html>

Richard.
Nov 26 '05 #15

P: n/a
On 2005-11-26, Michael Winter <m.******@blueyonder.co.uk> wrote:
Is it though? Surely two references to the same object, host object or
not, should still compare as equal? I realise that host objects aren't
governed by ECMA-262, but the equality operator is and it would seem
that that's decisive in this case.


unless the value of the object changed between references.

and what is compared when objects are compared anyway?

--

Bye.
Jasen
Nov 27 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.