Script in an IFRAME can not call functions defined in the parent document?

[Dave Hammond]

In document "A.html" I have defined a function and within the document
body have included an IFRAME element who's source is document "B.html".
In document "B.html" I am trying to call the function defined in
"A.html", but every attempt results in an "is not a function" error. I
have tried to invoke the function using parent.document.funcname(),
top.document.funcname(), and various other identifying methods, but all
result in the above error. Any pointers would be greatly appreciated!

Example code, document "A.html":

<script>
function foo()
{
alert("foo!");
}
</script>
....
<IFRAME src="B.html">No frames?</IFRAME>

Example code, document "B.html":
<script>
parent.document.foo();
// also tried... top.document.foo();
</script>

Thanks in advance!
-Dave H.

 

[Razzbar]

Try putting the call to foo in the iframe's body.onload event, and call
it with
top.foo() or parent.foo()

HTH

 

[Dave Hammond]

That worked, thanks! Actually I didn't even need to put it in the
onload event; just calling it as top.foo() rather than
top.document.foo() did the trick.

Thanks very much for the quick response!!

-Dave H.

 

[Ivo]

parent.document.foo();
// also tried... top.document.foo();

Functions are not properties of the document, but of the window.
Try
parent.foo();
or
top.foo();

You may want to perform some checks first:
if( parent.foo ) { // function exists, so go ahead
parent.foo();
}

Still a nasty error may occur if the parent is not in the same domain as
your iframe'd page, for example if your page is among Google Images results,
it will be loaded in a frame with a different host, and accessing any
property of parent will break the script, unless you wrap the code in a
try/catch block. It is therefore usually safer to put your scripts in the
top-document, and copy the necessary parts to the iframe onload.

hth
ivo
http://4umi.com/web/javascript/

 

[Razzbar]

What's especially neat is that you can assign a new function to the top
window from the iframe, then load another document in the iframe, and
the top window's new function is still available.

 

[Christopher J. Hahn]

What's especially neat is that you can assign a new function to the top
window from the iframe, then load another document in the iframe, and
the top window's new function is still available.

If I'm right, I believe that's because functions are primitive data
types in JS, like strings and numbers, so they're passed "by value" in
all operations, and not by reference.

So you're really ending up with a copy of the function, the same way
you would end up with a copy of a string or a number.

Granted, functions are *way* more useful to pass around this way than
strings or numbers.

 

[Richard Cornford]

If I'm right, I believe that's because functions are
primitive data types in JS, like strings and numbers,

Functions are object in javascript. And like all other objects they can
have named properties added to them, and assigned values, at any time.

so they're passed "by value" in all operations, and
not by reference.

<snip>

Being objects they are passed by reference only.

Richard.

 

[Christopher J. Hahn]

Functions are object in javascript. And like all other objects they can
have named properties added to them, and assigned values, at any time.

<snip>

Being objects they are passed by reference only.

Richard.

Not to be argumentative, but if they are passed by reference only then
could you explain why the referant isn't freed, causing an error in the
case described by Razzbar?

I've been too busy to actually test the case, mind you, but I'm fairly
sure he's correct.

 

[Martin Honnen]

Christopher J. Hahn wrote:

Not to be argumentative, but if they are passed by reference only then
could you explain why the referant isn't freed, causing an error in the
case described by Razzbar?

What does pass by reference or value have to do with the case of frames?
If you have a global variable in one frame then it is a property of the
window object of the frame thus if the iframe document does
parent.varName = someExpression
then a global variable in the parent window is set and that variable
does not change if a new document is loaded into the iframe as the
iframe has its own window object with its own variables.
Whether that expression evaluates to a primitive value or a function
object does not matter at all, there is not even a method or function
with arguments involved where the term passing by reference or value
makes sense.

 

[Christopher J. Hahn]

Christopher J. Hahn wrote:




What does pass by reference or value have to do with the case of frames?

Assign an object created in a child frame to a property of the parent
window, then navigate away from that document in the child frame and
attempt to manipulate the object in the parent window, and then maybe
you can tell me.
"Can't execute code from a free script."

If you have a global variable in one frame then it is a property of the
window object of the frame thus if the iframe document does
parent.varName = someExpression
then a global variable in the parent window is set and that variable
does not change if a new document is loaded into the iframe as the
iframe has its own window object with its own variables.

True, but if the variable is set as a reference (i.e. the object is
passed by reference to the assignment operator) then upon navigation of
the frame the referrant will been freed and the reference broken. In my
experience, further attempts to manipulate that object will result in
the error (in IE at least):
"Can't execute code from a freed script."

Try it out, as above.

This does not appear to be the case with functions or primitive values.

Whether that expression evaluates to a primitive value or a function
object does not matter at all, there is not even a method or function
with arguments involved where the term passing by reference or value
makes sense.

It is a function of operators that they receive values of some kind,
whether they be primitive values or references to objects (see also the
statement: ;+; ). I have commonly seen this provision of values to an
operator referred to as "passing". You might call it something else. It
makes no difference.

 

[Christopher J. Hahn]

Not to be argumentative, but if they are passed by reference only then
could you explain why the referant isn't freed, causing an error in the
case described by Razzbar?

I've been too busy to actually test the case, mind you, but I'm fairly
sure he's correct.

Richard,
Incidentally I did manage a *very* small test case and found that
by-reference-only appeared to be correct, though I didn't use frames or
anything.

But I really would appreciate it if you could explain to me why the
function object doesn't appear to be freed upon navigation like other
objects which are also members of the child window object. I think it
would clear up a lot of my confusion on this matter.

 

[Razzbar]

What does pass by reference or value have to do with the case of frames?
If you have a global variable in one frame then it is a property of the
window object of the frame thus if the iframe document does
parent.varName = someExpression
then a global variable in the parent window is set and that variable
does not change if a new document is loaded into the iframe as the
iframe has its own window object with its own variables.

Hmm... the iframe's document defines a function. The iframe's document
is a child of the iframe's window, so the iframe's function is part of
the of the iframe's window, which is part of the parent window...

Whether that expression evaluates to a primitive value or a function
object does not matter at all, there is not even a method or function
with arguments involved where the term passing by reference or value
makes sense.

But the question is, if top.foo() is a reference* to the foo() defined
in a document that has gone bye-bye, why does top.foo() still work?

If top.foo() = foo() //in the iframe's temporary document was an
assignment by value, it would make sense that it persists.

But if that's an assignment by reference, what would it be pointing to
after the defining document has changed?

 

[Richard Cornford]

Not to be argumentative,

Don't worry about being argumentative.

but if they are passed by reference only then could you
explain why the referant isn't freed, causing an error in
the case described by Razzbar?

Superficial testing is the most likely explanation of the behaviour
described. The bottom line is that calling a function that has been
defined in a frame that has unloaded via a reference to that function in
another frame is not going to work cross-browser. Confidence acquired by
only testing browsers where it does work is no indicator of reliability.

Consider what would happen where it does work. Think about garbage
collection. If the containing frame refers to a function that originates
in (and so in some sense belongs to) another frame's global object then
that function should not be able to be garbage collected when the
contents of that other frame unload. And as the function's scope chain
refers to the global object then that global object should not be
garbage collectable, and as the global object refers to the document
(and indirectly to its contents) the document should not be garbage
collectable, and so on. So where it works it is a brilliant way of tying
up a big chunk of memory in exchange for the ability to use what is
potentially a tiny function. (And might even result in talk of memory
leaks, where the memory consumption would in reality be the expected
consequences of behaviour being specifically programmed).

However, the execution environment of an unloaded frame is (to some
degree or another, in different browsers) dismantled and functions and
objects referred to by properties in different frames may start
producing errors if used. that is certainly the case for functions in
some versions of Windows IE 6, and if it doesn't work in Windows IE 6
then it has no potential application in a commercial project.

That this should happen, and that the results should differ considerably
between browsers (and browser versions) is not particularly surprising
as ECMAScript is designed for one global object, and one execution
environment, rather than multiple interacting environments. There is
simply no specified mechanism for the interactions between environments.

I've been too busy to actually test the case, mind you,
but I'm fairly sure he's correct.

Do try it.

Richard.

 

[Christopher J. Hahn]

Don't worry about being argumentative.

Courtesy is a pretense with a purpose.

Superficial testing is the most likely explanation of the behaviour
described. The bottom line is that calling a function that has been
defined in a frame that has unloaded via a reference to that function in
another frame is not going to work cross-browser. Confidence acquired by
only testing browsers where it does work is no indicator of reliability.

Consider what would happen where it does work. Think about garbage
collection. If the containing frame refers to a function that originates
in (and so in some sense belongs to) another frame's global object then
that function should not be able to be garbage collected when the
contents of that other frame unload. And as the function's scope chain
refers to the global object then that global object should not be
garbage collectable, and as the global object refers to the document
(and indirectly to its contents) the document should not be garbage
collectable, and so on. So where it works it is a brilliant way of tying
up a big chunk of memory in exchange for the ability to use what is
potentially a tiny function. (And might even result in talk of memory
leaks, where the memory consumption would in reality be the expected
consequences of behaviour being specifically programmed).

But there are other functionalities inherent in the language itself
that allow for remote creation of objects without resorting to the
ill-considered and clumsy implementation implied by the behavior to
which you're referring. There is no reason for a JS implementor to make
garbage collection quirky.

However, the execution environment of an unloaded frame is (to some
degree or another, in different browsers) dismantled and functions and
objects referred to by properties in different frames may start
producing errors if used. that is certainly the case for functions in
some versions of Windows IE 6, and if it doesn't work in Windows IE 6
then it has no potential application in a commercial project.

That this should happen, and that the results should differ considerably
between browsers (and browser versions) is not particularly surprising
as ECMAScript is designed for one global object, and one execution
environment, rather than multiple interacting environments. There is
simply no specified mechanism for the interactions between environments.

There's no reason the window object need be considered the top-level
object internally, so there's no reason for implementors to consider
the window to be an environment as opposed to another object in the
scope chain.

The problem seems to stem from the ambiguity of the relationship
between a document and its window. It would seem more intuitive (to me,
anyway) that variables and objects created by a document should be
properties of the document, rather than the window. Again, this is
obviously not the language's fault as (to my knowledge), the language
itself doesn't provide window or document objects.

This would be another point wehere I would like to see the W3C weigh
in.

Do try it.

Richard.

The ability to do things that I believe I should not expect to work is
something that I try to forget about, as it lends itself to bad
practice in other languages and/or past or future versions or other
implementations of the same language (like I mentioned with PERL's
automatic return of the value of the last expression in a function). To
me, thought should be just as portable as code.

Thanks for that excellent answer, Richard.




Sorry if any of what I've said makes little sense-- I've been pretty
swamped and my mind is scattered across many things at once. This week
I am thinking in PERL::threads+C. Next week I'll be thinking in
PHP/C+HTML again. The week after it'll be JS+PHP+NNTP+HTML, with some
MySQL on the side.

 

[Thomas 'PointedEars' Lahn]

Functions are object in javascript. And like all other objects they can
have named properties added to them, and assigned values, at any time.

<snip>

Being objects they are passed by reference only.

No. The known pass-by-* scheme of programming languages implementing
pointers does not apply here. A JS reference is not a pointer.

Objects in JS are only available via an object reference. One could say
that those references are passed to methods by value and that value is the
object. If you see it this way, it is quite clear why

function foo(x, y)
{
x = {bar: 42};
y.foobar = 23;
}

var y = {}, z = {};
foo(y, z);

does not result in (pseudocode)

y == {bar: 42, foobar: 23}

but in

y == {}
z == {foobar: 23}

The value of the first reference variable is changed to be assigned
a reference to a *new* object, and the value of the second reference
variable (i.e. the object) is changed to have a new property.


PointedEars

 

[Yann-Erwan Perio]

Thomas 'PointedEars' Lahn wrote:

function foo(x, y)
{
x = {bar: 42};
y.foobar = 23;
}

var y = {}, z = {};
foo(y, z);

does not result in (pseudocode)

y == {bar: 42, foobar: 23}

No one could ever expect that - that would be misunderstanding the
basics of scoping and assignment!

but in

y == {}
z == {foobar: 23}

That's true, but your example is, IMHO, too obscure to serve as a clear
demonstration of whichever point.

---
function foo(a, b) {
a = {bar: 42};
b.foobar = 23;
}

var y = {p:"y"}, z = {p:"z"};
foo(y, z);
---

The value of the first reference variable is changed to be assigned
a reference to a *new* object, and the value of the second reference
variable (i.e. the object) is changed to have a new property.

Explaining in what 'y' consist in the end, and why, would certainly help
to provide some insight on the way references and objects work in
javascript.


Regards,
Yep 'passing by reference'.

 

[Thomas 'PointedEars' Lahn]

No one could ever expect that - that would be misunderstanding the
basics of scoping and assignment!

No, if objects were 'always "passed by reference"' (as understood in a
language implementing pointers) as Richard stated, then x would be a
pointer to the object and an assignment to x would change the globally
defined object y. It does not, because only the reference is changed
to point to another object.

That's true, but your example is, IMHO, too obscure to serve as a clear
demonstration of whichever point.

---
function foo(a, b) {
a = {bar: 42};
b.foobar = 23;
}

var y = {p:"y"}, z = {p:"z"};
foo(y, z);
---

OK, that's more clear. However, if one understood scoping and the
pass-by-reference scheme, he would also understand my example.

Explaining in what 'y' consist in the end, and why, would certainly help
to provide some insight on the way references and objects work in
javascript.

[x] done


PointedEars

 

[Christopher J. Hahn]

No. The known pass-by-* scheme of programming languages implementing
pointers does not apply here. A JS reference is not a pointer.

Objects in JS are only available via an object reference. One could say
that those references are passed to methods by value and that value is the
object. If you see it this way, it is quite clear why

I don't see the effective difference between a reference passed by
value and a value passed by reference. Not in JS, anyway, which to my
knowledge provides no explicit means for referencing, dereferencing,
nor threading.

Either way, you end up with a reference to the value.

Functionally there's no difference, is there?

function foo(x, y)
{
x = {bar: 42};
y.foobar = 23;
}

var y = {}, z = {};
foo(y, z);

does not result in (pseudocode)

y == {bar: 42, foobar: 23}

but in

y == {}
z == {foobar: 23}

Even given the way of thinking that the referenced object is being
passed by reference, this is equally clear.

The only difference (and I wouldn't call it a "real" difference) is
that, by saying it is being passed by reference, there's an implied
step of dereferencing, which I'm assuming doesn't actually occur.

The value of the first reference variable is changed to be assigned
a reference to a *new* object, and the value of the second reference
variable (i.e. the object) is changed to have a new property.

Because we're not talking pointers, but references, right?

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

I don't see the effective difference between a reference passed by
value and a value passed by reference. Not in JS, anyway, which to my
knowledge provides no explicit means for referencing, dereferencing,
nor threading.

Either way, you end up with a reference to the value.

Functionally there's no difference, is there?

Because we're not talking pointers, but references, right?

Yes.


PointedEars

 

[Yann-Erwan Perio]

Thomas 'PointedEars' Lahn wrote:

Hi,

No, if objects were 'always "passed by reference"' (as understood in a
language implementing pointers) as Richard stated, then x would be a
pointer to the object and an assignment to x would change the globally
defined object y. It does not, because only the reference is changed
to point to another object.

Just to clarify : I was not referring to the pointers/references issue,
but simply to the fact that 'y' becoming {bar:42, foobar:23} would not
be possible, whichever perspective (reference or pointer) - y.foobar in
the function's body would indeed apply on the object behind 'z'. This is
why I suggested, later in my post, a change in the arguments' names.

<snip>


Regards,
Yep.