What's the correct behaviour ?

Jorge · Sep 26, 2009

Let's say that you've got a page like this:

<html>
<head>
<script>
window.onload= function () {
(function f1 () {
alert("f1()");
setTimeout(f1, 3333);
})();

document.write("another page");
};
</script>
</head>
<body>
</body>
</html>

Once the document.write happens, should f1() be killed or should it
stay alive-n-kickin' ?
I ask because both Opera and IE8 kill it, while Safari, Chrome and
FireFox do not.
What's the correct behaviour ?

You can test it @ jorgechamorro.com/cljs/083/index4.html

TIA,

Bart Van der Donck · Oct 4, 2009

Jorge said:
Let's say that you've got a page like this:

<html>
<head>
<script>
window.onload= function () {
(function f1 () {
alert("f1()");
setTimeout(f1, 3333);
})();

document.write("another page");
};
</script>
</head>
<body>
</body>
</html>
[...] You can test it @ jorgechamorro.com/cljs/083/index4.html
[...] I ask because both Opera and IE8 kill it, while Safari, Chrome
and FireFox do not.

My tests show the same result, except Firefox:

Chrome 3.0.195.: not killed
MSIE 8.0.600.: killed (showed once)
Firefox 3.0.14.: killed (showed once)
Opera 9.22.: killed (showed once)

IMHO the issue is a mere document.write issue after the page has been
fully loaded. See e.g.:

body onLoad="document.write('1');setTimeout('alert(\'2\')',100);"

Chrome 3.0.195.: shows only '2'
MSIE 8.0.600.: shows both '1' and '2'
Firefox 3.0.14.: shows only '1'
Opera 9.22.: shows only '1'

Once the document.write happens, should f1() be killed or should it
stay alive-n-kickin' ?

Theoretically I would expect that 'f1()' should be no longer
available, since document.write clears all elements of the current
page (it is called after page load). But the cleared page should also
have this same window-object, but now cleared; in that view a
setTimeout()-call should be okay; although this is firmly contradicted
by my tests above

Maybe the logic is that 'setTimeout()' may still
refer to the old uncleared window-object. In my tests Chrome appears
to be the only browser that realizes that 'f1()' is still needed and
takes it to "the next level" and neglecting the actual complete
'clear'-command.

What's the correct behaviour ?

I would not speak in terms of correct/incorrect, but about different
implementations of document.write. Interesting case, but not for
production use, I'ld say...

Jorge · Oct 21, 2009

Jorge said:
Jorge said:

Let's say that you've got a page like this:

Click to expand...

<html>
<head>
<script>
window.onload= function () {
(function f1 () {
alert("f1()");
setTimeout(f1, 3333);
})();

Click to expand...

document.write("another page");
};
</script>
</head>
<body>
</body>
</html>
[...] You can test it @ jorgechamorro.com/cljs/083/index4.html
[...] I ask because both Opera and IE8 kill it, while Safari, Chrome
and FireFox do not.

Click to expand...

My tests show the same result, except Firefox:

Chrome 3.0.195.: not killed
MSIE 8.0.600.: killed (showed once)
Firefox 3.0.14.: killed (showed once)
Opera 9.22.: killed (showed once)

IMHO the issue is a mere document.write issue after the page has been
fully loaded. See e.g.:

body onLoad="document.write('1');setTimeout('alert(\'2\')',100);"

Chrome 3.0.195.: shows only '2'
MSIE 8.0.600.: shows both '1' and '2'
Firefox 3.0.14.: shows only '1'
Opera 9.22.: shows only '1'

Once the document.write happens, should f1() be killed or should it
stay alive-n-kickin' ?

Click to expand...

Theoretically I would expect that 'f1()' should be no longer
available, since document.write clears all elements of the current
page (it is called after page load). But the cleared page should also
have this same window-object, but now cleared; in that view a
setTimeout()-call should be okay; although this is firmly contradicted
by my tests above Maybe the logic is that 'setTimeout()' may still
refer to the old uncleared window-object. In my tests Chrome appears
to be the only browser that realizes that 'f1()' is still needed and
takes it to "the next level" and neglecting the actual complete
'clear'-command.

What's the correct behaviour ?

Click to expand...

I would not speak in terms of correct/incorrect, but about different
implementations of document.write. Interesting case, but not for
production use, I'ld say...

Bart,

Oops, somehow I missed your reply...

Yes, it looks like if (the global object) window is being recreated
from scratch in some browsers and reused in others, as far as I can
see.

Thanks !

VK · Oct 21, 2009

Jorge said:
Yes, it looks like if (the global object) window is being recreated
from scratch in some browsers and reused in others, as far as I can
see.

If you are interested in the orphaned scripts (this is what you are
asking about) I dare to suggest "Pattern on delayed action" discussion
from 2003 with my comments:
http://groups.google.com/group/comp..._frm/thread/c56aa6ddf79cccf4/c61ad72002442f2e
An "orphaned script" is exactly a code that is being executed despite
its Global is theoretically vanished together with the page it
originally arrived with / on.

Even more troubles prone derivation of this kind is a "freed script":
this is a code on its own page and with its own Global but having
object instances created by constructors in another Global (from
another window / frame).

Both kinds, especially the last one, are one of beloved by hackers to
see if a memory corruption would be possible and respectively are
under a strong scrutiny of the development teams. Respectively the
exact results may differ greatly by brands depending on the chosen
protection mechanics. Either one is the "correct behavior" as long as
it protects the system: AFAIK there is not an international body
openly regulating memory corruption and hacker attacks protection all
UAs wide

VK · Oct 21, 2009

Even more troubles prone derivation of this kind is a "freed script":

this is a code on its own page and with its own Global but having
object instances created by constructors in another Global (from
another window / frame).

I forgot to add: with that another Global disappeared by frame loaded
another page yet the freed script holding instances with technically
valid references to constructors, prototypes etc from the gone Global.

Another oftenly tried hack approach to try to break the system by
"virtualized nodes": getting a reference to an existing DOM element,
removing the element from the actual tree, the rest up to one's
personal fantasy, for instance use this reference for a freed script,
make orphaned etc. Back in 2002-2003 it caused a huge security and
stability breakout to IE. I cannot find Eric Lippert's blog article I
once referenced in this group, maybe later. Here again the "correct
behavior" bould be anything as long as it protects the system though
the common trend now seems to be to have an internal "DOM elements"
cache and do not remove anything until last possible potential or
actual freed script and orphaned script is gone from the scope. It
costs some serious memory of course, but on the security scale the
memory is the cheapest resource.

Only one table shows up with the information	2	Mar 29, 2023
Strange diacritcs behaviour (IE issue)	5	Feb 4, 2008
Need help again please	19	Feb 14, 2020
really dumb error but it's stumped me	20	Jun 2, 2010
Browser behaviour in javascript redirect!	0	Aug 7, 2008
Different behaviour on Netscape.	6	Sep 23, 2008
IE is not redirecting the output to the correct frame	2	Oct 19, 2004
Why doesn't frameset onload event get called when each of the frames has an onload?	5	May 4, 2005

What's the correct behaviour ?

Jorge

Bart Van der Donck

Jorge

VK

VK

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads