Thomas Christensen wrote:
If anyone can provide an explanation and/or workaround for
this bug in IE I would be really grateful.
I think this is a bug in IE, at least in ECMAScript terms it is a bug.
It might be argued that the functions created from the values of
intrinsic event attributes are in the realm of host objects and so can
exhibit any behaviour that the browser authors want them to. And it has
been demonstrated that the functions created from intrinsic even vales
have some extremely odd characteristics in their (apparently dynamic)
scope chain assignment.
Is this a known bug?:
I don't know about it being a 'known bug' as such, it is an area where
odd behaviour is expected on IE browsers.
******CODE***** **
<html>
<script type="text/javascript">
function mf(){return function(){aler t('succes!')}}
</script>
<body>
<form>
<span onclick="f1=mf( );alert(f1);set Timeout('f1()', 1);">in form</span>
<snip>
The question that I asked first is where is - f1 - in the scope chain.
Inserting - alert(f1) - prior to the assignment produces a - f1 is
undefined error - so f1 is not on the scope chain prior to its
assignment. Thus the assignment must add it as a property of some object
on the scope chain.
It is not a property of the global object else the - setTimeout - would
not error. But replacing the content of the existing - alert(f1) -
with:-
this.f1 // undefined - it is not a property of the SPAN element.
document.f1 // undefined - it is not a property of the document.
document.docume ntElement.f1 // undefined - it is not a property
// of the HTML element.
document.body.f 1 // undefined - it is not a property of the BODY
// element.
docuemnt.forms[0].f1 // undefined - it is not a property of the FORM.
- leaves only one apparent candidate from ECMAScript for the object to
which the property is added, and that is the Variable/Activation object
of the internally generated even handling function (the only object that
cannot actually be examined). However, this can be ruled out by
replacing the form with:-
<form>
<span onclick="f1=mf( );alert(f1);">i n form</span><br>
<span onclick="alert( f1);">second test</span>
</form>
- where clicking "in form" adds the property to some object and then
clicking "second test" alerts the function string. Thus whichever object
has had the property added it is not an object inside the execution
context of the first even handling function, else the second would not
be able to see the - f1 - property on its scope chain.
Now, we know that there is no - f1 - property on the scope chain prior
to the assignment, and we know that an unqualified identifier (- f1 - in
this case) would be resolved against the scope chain and if it did not
exist an internal Reference type with a null "Base" object would be
returned (ECMA 262 3rd edition; Section 10.1.4). And we know that the
ECMA 262 specified internal - PutValue - function will react to
instructions to assign to a Reference with a null "Base" object by using
the global object as the object on which to call the [[Put]] method
(ECMA 262 3rd Edition; section 8.7.2).
So the expected behaviour of the assignment - f1 = mf(); -, where an
'f1' property does not already exist on any object on the scope chain,
is to create a new property of the global object called 'f1' and assign
the value to that. But that is not what is happening.
The only reasonable explanation for the behaviour demonstrated is that
for functions created form intrinsic event handling attributes inside
forms a different 'global' object masks the real global object during
assignments, and subsequent retrievals. The addition of a second form:-
<form>
<span onclick="f1=mf( );alert(f1);">i n form</span><br>
</form>
<form>
<span onclick="alert( f1);">second test</span>
</form>
- demonstrates that this additional 'global' object is form-specific, as
clicking on 'second test' in the second form, after the use of 'in form'
in the first, again produces the - f1 is undefined - error.
In ECMAScript terms the behaviour demonstrated is incorrect, in an
actual environment, such as IE, and in relation to the behaviour of
host-provided objects, it is much more questionable whether this would
qualify as a bug or a feature. On the other hand, with IEs problems with
circular references having an additional and inaccessible 'global'
object in the system may be extremely problematic.
The possible "workaround "s (incidentally, last week I discovered that in
French there is no word for "workaround "; did they never workaround? Is
it really an alien concept?) may be to follow general programming advice
and not be in the business of trying to create global variables on the
fly, or using global variables where their use could be avoided. In this
case, modern browsers allow - setTimeout - to take a function reference
as its first argument instead of a string of code, so:-
onclick="setTim eout(mf(),1);"
- would get the job done without any need to assign a value to any
object's property. (That is not without its issues as even browsers as
recent as, at lest some early, Safari versions do not understand
function references in this context, though there is a workaround for
that also.)
Then there is the general advice that if you are going to be using
global variable they should all be _explicitly_ declared in the global
scope. Doing so in your example:-
<html>
<script type="text/javascript">
var f1, f2; /*<-- Declare f1 and f2 as global variables. */
function mf(){return function(){aler t('succes!')}}
</script>
<body>
<form>
<span onclick="f1=mf( );alert(f1);set Timeout('f1()', 1);">in form</span>
</form>
<span onclick="f2=mf( );alert(f2);set Timeout('f2()', 1);">out of form
</span>
</body>
</html>
- prevents the - setTimeout - in "in form" from erroring. As now when
the unqualified identifier - f1 - is referenced in the assignment the
internal Reference type that results has the global object explicitly
assigned to its "Base" property and so there is no ambiguity in which
object should have its [[Put]] method used for the assignment. The
assigned value ends up on the global object as initially expected.
This is the irony in asking if this is a 'known bug', because while I
had observed that the event handling functions IE generates form
intrinsic event attribute values have some extremely strange
characteristics (particularly if you start moving them around in the DOM
or executing them in the global scope) I had never observed this
particular behaviour. Because I habitually minimise the number of global
variables I use, and I explicitly declare those that I do use. Both in
accordance with what are widely held "Best Practices" in javascript
authoring, and both coincidentally acting to avoid provoking this issue.
There will be a strong tendency for individuals who know enough to
effectively analyse this problem to have also learnt (possibly the hard
way) to apply sufficient "Best Practices" to their code to never
encounter the issue themselves. You did the right thing in providing a
specific test-case that demonstrates the issue in isolation. Others
assert that they have issues but in never demonstrating them find their
clams being ignored as probably resulting from erroneous coding that can
only be fruitlessly guessed at, as it cannot be seen.
Richard.
