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

(another) infuriating IE bug

P: n/a
If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:

******CODE*******
<html>
<script type="text/javascript">
function mf(){return function(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>

<span onclick="f2=mf();alert(f2);setTimeout('f2()',1);"> out of form</span>

</body>
</html>
***************

Thomas
thom [at] schristensen [.] com
Oct 13 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
> "Thomas Christensen" <th**@schristensen.com> wrote:
news:43***********************@dread12.news.tele.d k....

If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:

******CODE*******
<html>
<script type="text/javascript">
function mf(){return function(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>

<span onclick="f2=mf();alert(f2);setTimeout('f2()',1);"> out of
form</span>

</body>
</html>
***************

Thomas
thom [at] schristensen [.] com


<script type="text/javascript">
var f1;
var f2;
function mf(){return function(){alert('succes!')}}
</script>

--
BootNic Thursday, October 13, 2005 2:13 PM

Every time I close the door on reality it comes in through the windows.
*Jennifer Unlimited*
Oct 13 '05 #2

P: n/a
Thanx! I kinda knew. But in my application I'll probably have to
hardcode the object-reference in the inline setTimeout... And handle
cancellations... But why this behaviour?!

BootNic wrote:
"Thomas Christensen" <th**@schristensen.com> wrote:
news:43***********************@dread12.news.tele .dk....

If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:

******CODE*******
<html>
<script type="text/javascript">
function mf(){return function(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>

<span onclick="f2=mf();alert(f2);setTimeout('f2()',1);"> out of
form</span>

</body>
</html>
***************

Thomas
thom [at] schristensen [.] com

<script type="text/javascript">
var f1;
var f2;
function mf(){return function(){alert('succes!')}}
</script>

Oct 13 '05 #3

P: n/a
On Thu, 13 Oct 2005 20:23:56 +0200, Thomas Christensen
<th**@schristensen.com> wrote:
Thanx! I kinda knew. But in my application I'll probably have to
hardcode the object-reference in the inline setTimeout... And handle
cancellations... But why this behaviour?!


because setTimeout executes in the global scope, it doesn't execute in
the scope it's called in.

This is not an IE bug.

Jim.
Oct 13 '05 #4

P: n/a
Works fine in Mozilla. And it's only when enclosed in a <form></form> it
won't work in IE. So <form> is another scope than everything else in IE?
I suspected as much, but don't get it...

Sorry if I'm being daft, but I'm back to coding client stuff after a few
years... Thanks for your reply!

Jim Ley wrote:
On Thu, 13 Oct 2005 20:23:56 +0200, Thomas Christensen
<th**@schristensen.com> wrote:

Thanx! I kinda knew. But in my application I'll probably have to
hardcode the object-reference in the inline setTimeout... And handle
cancellations... But why this behaviour?!

because setTimeout executes in the global scope, it doesn't execute in
the scope it's called in.

This is not an IE bug.

Jim.

Oct 13 '05 #5

P: n/a
JRS: In article <43***********************@dread12.news.tele.dk> , dated
Thu, 13 Oct 2005 19:36:03, seen in news:comp.lang.javascript, Thomas
Christensen <th**@schristensen.com> posted :
If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:


The code does what it should do.

The bug is in your expectation of what it should do; but you have not
explained what that might be.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Oct 14 '05 #6

P: n/a
Thomas Christensen wrote:
If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:

******CODE*******
<html>
<script type="text/javascript">
function mf(){return function(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>

<span onclick="f2=mf();alert(f2);setTimeout('f2()',1);"> out of form</span>

</body>
</html>
***************

Solution. If you add the created function to an object in the global
scope it works fine. I still don't understand why IE make the
<form></form> it's own scope, but that's just me:

<script type="text/javascript">
function mf(){return function(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="mf.f1=mf();alert(mf.f1);setTimeout('mf.f1 ()',1);">in
form</span>
</form>

<span onclick="mf.f2=mf();alert(mf.f2);setTimeout('mf.f2 ()',1);">out
of form</span>
Oct 15 '05 #7

P: n/a
Dr John Stockton wrote:
JRS: In article <43***********************@dread12.news.tele.dk> , dated
Thu, 13 Oct 2005 19:36:03, seen in news:comp.lang.javascript, Thomas
Christensen <th**@schristensen.com> posted :

If anyone can provide an explanation and/or workaround for this bug in
IE I would be really grateful. Is this a known bug?:

The code does what it should do.

The bug is in your expectation of what it should do; but you have not
explained what that might be.

I don't think the code does what it should do. The setTimout can't see
f2 when enclosed in a form even though f2 is created inside the same
form. Maybe I don't understand the DOM, but I can't see why <form>
should be an individual scope when no other html-blocks is.

The code in it's actual implementation is used to hide a popup that is
dynamically created, but that's not the point. It's the scope-thing that
annoy me.
Oct 15 '05 #8

P: n/a
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(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('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.documentElement.f1 // undefined - it is not a property
// of the HTML element.
document.body.f1 // 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);">in 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);">in 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="setTimeout(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(){alert('succes!')}}
</script>
<body>
<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>
<span onclick="f2=mf();alert(f2);setTimeout('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.

Oct 16 '05 #9

P: n/a
Hi Richard

Thanx a lot for your thourough answer, which sums ups my suspections in
a way I couldn't hope to achieve.

My problem was that I needed to add a setTimout on a function with a
reference to the object (which was dynamically created) in which the
setTimout occurred. And I could not get

<span onclick="setTimout(mf(this),100)">

to work for obvious reasons. I now there are workarounds (incidentally
we don't really have a word for workaround in Danish either, so we use -
"workaround") but I don't like workarounds, so...

As I posted earlier I solved the problem in a for me elegant way(?) by
adding the created fundctions to a pseudo namespace (a global function -
in this case the mf function). So:

mf.f1=mf(this);setTimeout('mf.f1()',100);

And that works fine. And better than declaring "f1" as a variable in the
global scope as I in the actual case didn't know how many
derived/created functions I would need.

Thanx
Thomas

Richard Cornford wrote:
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(){alert('succes!')}}
</script>
<body>

<form>
<span onclick="f1=mf();alert(f1);setTimeout('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.documentElement.f1 // undefined - it is not a property
// of the HTML element.
document.body.f1 // 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);">in 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);">in 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="setTimeout(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(){alert('succes!')}}
</script>
<body>
<form>
<span onclick="f1=mf();alert(f1);setTimeout('f1()',1);"> in form</span>
</form>
<span onclick="f2=mf();alert(f2);setTimeout('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.

Oct 16 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.