(another) infuriating IE bug

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

> "Thomas Christensen" <thom@schristensen.com> wrote:[color=blue]
> news:434e9b04$0$38671$edfadb0f@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[/color]

<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*

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:[color=blue][color=green]
>>"Thomas Christensen" <thom@schristensen.com> wrote:
>>news:434e9b04$0$38671$edfadb0f@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[/color]
>
>
> <script type="text/javascript">
> var f1;
> var f2;
> function mf(){return function(){alert('succes!')}}
> </script>
>
>
>[/color]

On Thu, 13 Oct 2005 20:23:56 +0200, Thomas Christensen
<thom@schristensen.com> wrote:
[color=blue]
>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?![/color]

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.

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:[color=blue]
> On Thu, 13 Oct 2005 20:23:56 +0200, Thomas Christensen
> <thom@schristensen.com> wrote:
>
>[color=green]
>>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?![/color]
>
>
> 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.[/color]

JRS: In article <434e9b04$0$38671$edfadb0f@dread12.news.tele.dk> , dated
Thu, 13 Oct 2005 19:36:03, seen in news:comp.lang.javascript, Thomas
Christensen <thom@schristensen.com> posted :
[color=blue]
>If anyone can provide an explanation and/or workaround for this bug in
>IE I would be really grateful. Is this a known bug?:[/color]

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.

Thomas Christensen wrote:[color=blue]
> 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>
> ***************[/color]

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>

Dr John Stockton wrote:[color=blue]
> JRS: In article <434e9b04$0$38671$edfadb0f@dread12.news.tele.dk> , dated
> Thu, 13 Oct 2005 19:36:03, seen in news:comp.lang.javascript, Thomas
> Christensen <thom@schristensen.com> posted :
>
>[color=green]
>>If anyone can provide an explanation and/or workaround for this bug in
>>IE I would be really grateful. Is this a known bug?:[/color]
>
>
> 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.
>[/color]
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.

Thomas Christensen wrote:[color=blue]
> If anyone can provide an explanation and/or workaround for
> this bug in IE I would be really grateful.[/color]

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.
[color=blue]
> Is this a known bug?:[/color]

I don't know about it being a 'known bug' as such, it is an area where
odd behaviour is expected on IE browsers.
[color=blue]
> ******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>[/color]
<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.

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:[color=blue]
> Thomas Christensen wrote:
>[color=green]
>>If anyone can provide an explanation and/or workaround for
>>this bug in IE I would be really grateful.[/color]
>
>
> 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.
>
>[color=green]
>>Is this a known bug?:[/color]
>
>
> I don't know about it being a 'known bug' as such, it is an area where
> odd behaviour is expected on IE browsers.
>
>[color=green]
>>******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>[/color]
>
> <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.
>
>
>[/color]

(another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

re: (another) infuriating IE bug

Similar JavaScript / Ajax / DHTML bytes

/bytes/development

/bytes/it

/bytes/about