foist javascript upon another frame

Phlip

Javascripters:

I have a page with an iframe inside. Let's say the iframe looks like this:

<script src="/javascripts/prototype.js" type="text/javascript" />
....
<iframe id='grinder' src='sample.html' >
</iframe>

That prototype.js gives us goodies like $(). And sample.html looks a little
bit like this:

<html><body bgcolor='silver'>
<span id='update_me'>yo</span>
</body></html>

Now I want to write a function that pushes some JavaScript into the iframe,
and evaluates it there. Should I use eval()? Is there some way to make
eval() execute in a frame's context?

Or should I foolishly write a function, in another js header, like this?

function update_grinder(nu_script)
{
var grinder = $('grinder');

if (grinder)
{
var doc = grinder.contentDocument;
if (!doc) doc = grinder.document;
if (doc)
{
doc.body.innerHTML += '<script>' + nu_script + '</script>';
return;
}
}
document.write(" your browser lacks decent iframes");
}

And that doesn't work. The iframe appears to twitch (it will lose a
selection emphasis, for example), but it doesn't evaluate my script.

(For the script.aculo.us-enlightened, the script is just
Element.update("update_me", "here I B"), and it is correctly escaped and
transmitted. alert() statements can see it, just before the innerHTML+= line
where it does not work. Without the <scripttags, the new JS appears as
source, and with them it simply doesn't evaluate.

Can't I just say something obvious like doc.body.script = nu_script, or
less??

Please don't ask why I want to do this; I'm not attacking someone else's
page, or trying to write a public site using extra-fragile code. I just ...
need to do it!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #1

Subscribe Reply

1809

Randy Webb

Phlip said the following on 12/16/2006 1:11 AM:

Javascripters:

I have a page with an iframe inside. Let's say the iframe looks like this:

<script src="/javascripts/prototype.js" type="text/javascript" />

<iframe id='grinder' src='sample.html' >
</iframe>

That prototype.js gives us goodies like $(). And sample.html looks a little
bit like this:

What you call a "goodies" a lot of people call crap.

<html><body bgcolor='silver'>
<span id='update_me'>yo</span>
</body></html>

Why the HTML3.2 code?

Now I want to write a function that pushes some JavaScript into the iframe,
and evaluates it there. Should I use eval()? Is there some way to make
eval() execute in a frame's context?

eval? Sure if you don't know any better. If you want prototype
functionality in your IFrame, why don't you simply load prototype into
the IFrame?

IFrameRef.document.write('<script type="text/javascript"
src="prototype.js"><\/script>');

Or should I foolishly write a function, in another js header, like this?

Now that *would* be foolish. Don't make it harder than it has to be.

And that doesn't work. The iframe appears to twitch (it will lose a
selection emphasis, for example), but it doesn't evaluate my script.

That is because scripts inserted via innerHTML don't get executed (with
two rare exceptions).

Can't I just say something obvious like doc.body.script = nu_script, or
less??

See above.

If all else fails, search the archives for "Randy Webb LoadJSFile()" and
enjoy the reading.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #2

Phlip

Randy Webb wrote:

<script type="text/javascript" src="/.../"></script>

Don't use XHTML style in a general context. The fact that prototype got
loaded at all is amazing.

Rails generated that; address their maintainers if it offends you. It seems
to work for Web 2.0 stuff, but I have not bothered to research the exact
limits. I seem to recall stating the project was not directly for public
consumption...

><iframe id='grinder' src='sample.html' >
</iframe>

That prototype.js gives us goodies like $(). And sample.html looks a
little bit like this:

What you call a "goodies" a lot of people call crap.

It is unfortunate that prototype.js must be mentioned to comprehend the
peripheral issues of the post, but it's completely not the point.

><html><body bgcolor='silver'>
<span id='update_me'>yo</span>
</body></html>

Why the HTML3.2 code?

Because I wrote it with the equivalent of Notepad (and not with Rails), as
an example.

>Now I want to write a function that pushes some JavaScript into the
iframe, and evaluates it there. Should I use eval()? Is there some way to
make eval() execute in a frame's context?

eval? Sure if you don't know any better. If you want prototype
functionality in your IFrame, why don't you simply load prototype into the
IFrame?

Do you see the little ? after where I wrote "eval()"?

No, I don't need to import prototype.js into my IFrame. Not sure why you
couldn't see past that apparently offensive library. I really don't think I
did so poorly writing the post. All I want to do is transport a segment of
JS, as a string, into the IFrame, and evaluate it in the context of the
recipient document. The string calls prototype.js - it could call alert()
for all I care, so long as I can transport it.

But thanks for making this thread look like my question has been answered.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #3

Phlip

[I took the Re: off because this is not answered yet...]

Phlip wrote:

Javascripters:

I have a page with an iframe inside. Let's say the iframe looks like this:

<script src="/javascripts/prototype.js" type="text/javascript" />
...
<iframe id='grinder' src='sample.html' >
</iframe>

That prototype.js gives us goodies like $(). And sample.html looks a
little bit like this:

<html><body bgcolor='silver'>
<span id='update_me'>yo</span>
</body></html>

That also includes prototype.js, which is _not_ the point of this post.

Now I want to write a function that pushes some JavaScript into the
iframe, and evaluates it there. Should I use eval()? Is there some way to
make eval() execute in a frame's context?

Or should I foolishly write a function, in another js header, like this?

function update_grinder(nu_script)
{
var grinder = $('grinder');

if (grinder)
{
var doc = grinder.contentDocument;
if (!doc) doc = grinder.document;
if (doc)
{
doc.body.innerHTML += '<script>' + nu_script + '</script>';
return;
}
}
document.write(" your browser lacks decent iframes");
}

And that doesn't work. The iframe appears to twitch (it will lose a
selection emphasis, for example), but it doesn't evaluate my script.

(For the script.aculo.us-enlightened, the script is just
Element.update("update_me", "here I B"), and it is correctly escaped and
transmitted. alert() statements can see it, just before the innerHTML+=
line where it does not work. Without the <scripttags, the new JS appears
as source, and with them it simply doesn't evaluate.

Can't I just say something obvious like doc.body.script = nu_script, or
less??

Please don't ask why I want to do this; I'm not attacking someone else's
page, or trying to write a public site using extra-fragile code. I just
... need to do it!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #4

Randy Webb

Phlip said the following on 12/16/2006 3:07 AM:

Randy Webb wrote:

><script type="text/javascript" src="/.../"></script>

Don't use XHTML style in a general context. The fact that prototype got
loaded at all is amazing.

Rails generated that; address their maintainers if it offends you. It seems
to work for Web 2.0 stuff, but I have not bothered to research the exact
limits. I seem to recall stating the project was not directly for public
consumption...

No, you only commented that you didn't want to use fragile code.

>><iframe id='grinder' src='sample.html' >
</iframe>

That prototype.js gives us goodies like $(). And sample.html looks a
little bit like this:
What you call a "goodies" a lot of people call crap.

It is unfortunate that prototype.js must be mentioned to comprehend the
peripheral issues of the post, but it's completely not the point.

It's actually irrelevant to the question.

>>Now I want to write a function that pushes some JavaScript into the
iframe, and evaluates it there. Should I use eval()? Is there some way to
make eval() execute in a frame's context?
eval? Sure if you don't know any better. If you want prototype
functionality in your IFrame, why don't you simply load prototype into the
IFrame?

Do you see the little ? after where I wrote "eval()"?

That is why I answered the question.

No, I don't need to import prototype.js into my IFrame. Not sure why you
couldn't see past that apparently offensive library.

It had nothing to do with it being prototype. If I were indicating my
opinion of prototype I would have told you to load protocrap into your
IFrame.

I really don't think I id so poorly writing the post. All I want to do is
transport a segment of JS, as a string, into the IFrame, and evaluate it
in the context of the recipient document.

Create a script block, set it's text property, and then appendChild it
to the document. Just remember that it suffers the same security
restrictions as cross-domain scripting. If both documents are yours, it
isn't a problem.

The string calls prototype.js - it could call alert()
for all I care, so long as I can transport it.

I don't care to type it again, I have typed it about 100 times in the
past (not to you though). If you search for my name and loadJSFile the
threads you will find explain how to "inject" scripts into a document.
If you find the thread "createTextNode and IE7" that was posted in
today, it deals with doing about what you are doing - injecting script
segments (as a string) into a document. It even links to a page where it
shows what browsers support what methods of doing what you are wanting
to do.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #5

Randy Webb

Phlip said the following on 12/16/2006 3:12 AM:

[I took the Re: off because this is not answered yet...]

Yes it was, it just wasn't the answer you wanted.

loadJSFile and insertScript in the archives will explain, in great
detail across threads, how to accomplish what you want to do.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #6

Phlip

Randy Webb wrote:

Phlip said the following on 12/16/2006 3:12 AM:

I think someone needs some nappy time ;-)

>[I took the Re: off because this is not answered yet...]

Yes it was, it just wasn't the answer you wanted.

loadJSFile and insertScript in the archives will explain, in great detail
across threads, how to accomplish what you want to do.

And it turns out both your answers - to insert prototype.js, and to use the
techniques on your page, were incorrect. So they were indeed the answers I
didn't want.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #7

Phlip

Randy Webb wrote:

>I seem to recall stating the project was not directly for public
consumption...

No, you only commented that you didn't want to use fragile code.

"I'm not ... trying to write a public site..."

Not sure how much clearer I could have been. Maybe I should have put it up
at the top, to reduce the risk of bragging about standards compliance
awareness...

>>eval? Sure if you don't know any better. If you want prototype
functionality in your IFrame, why don't you simply load prototype into
the IFrame?

Do you see the little ? after where I wrote "eval()"?

That is why I answered the question.

I don't think I asked "should I use eval to import prototype.js"...

Create a script block, set it's text property, and then appendChild it to
the document. Just remember that it suffers the same security restrictions
as cross-domain scripting. If both documents are yours, it isn't a
problem.

Your sample page, while generally studious, does not actually do anything to
the target page at load time. All it does is load the JS and demonstrate an
'alert()'. This does not prove the JS worked in the context of the target
browser.

I'm not done researching all permutations (including a corroboration of your
createElement('script') technique at
http://www.dotvoid.com/view.php?id=13 ), but I have a most curious
discrepancy between IE and Firefox to report. Here's the rig so far:

function evaluate(doc, sauce)
{
var s = doc.createElement('script');
s.text = sauce;
var head = doc.getElementsByTagName('head').item(0);

if (head)
{
head.appendChild(s);
return;
}
head = doc.head;
if (head)
{
head.appendChild(s);
return;
}
}
function update_grinder(sauce)
{
var grinder = $('grinder');

if (grinder)
{
var doc = grinder.contentDocument;
if (!doc) doc = grinder.document;
if (doc)
{
evaluate(doc, sauce);
return;
}
}
document.write("your browser sucks");
}

Now suppose the 'sauce' contained your favorite JS line in the whole world,
'Element.update("update_me", "here I B");'. And suppose both the outer and
inner HTML have a <span id='update_me'>. When I run that code....

- IE updates the wrong $('update_me') - the one in the outer HTML
- only Firefox gets the context right and evaluates the inner HTML.

Konqeror and Opera did nothing. Naturally, when I take out the outer
'update_me', IE just gives an error. I am open to the possibility of a bug
in the $() inside of prototype.js, which is where I will investigate next,
but does that make Firefox the wrong one?

So it would seem your page tests alert() more thoroughly than it tests the
issues of javascript insertion...

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #8

Randy Webb

Phlip said the following on 12/16/2006 6:14 AM:

Randy Webb wrote:

>Phlip said the following on 12/16/2006 3:12 AM:

I think someone needs some nappy time ;-)

I probably do.

>>[I took the Re: off because this is not answered yet...]
Yes it was, it just wasn't the answer you wanted.

loadJSFile and insertScript in the archives will explain, in great detail
across threads, how to accomplish what you want to do.

And it turns out both your answers - to insert prototype.js,

The answer was not unique to prototype.js, it could be
myHumptyDumptyAnimatedScript.js and the principle is the same.

and to use the techniques on your page, were incorrect.

If you are trying to dynamically insert scripts in a page then the
techniques on the page are two solutions, depending on what the end
effect is desired to be.

To simply want a function that accepts a string parameter that is
javascript code and execute that code then you have three alternatives:

1) createElement and set the .text property
2) createElement and use createTextNode which IE pukes on
3) eval the string.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #9

Randy Webb

Phlip said the following on 12/16/2006 5:30 AM:

Randy Webb wrote:

>>I seem to recall stating the project was not directly for public
consumption...

>No, you only commented that you didn't want to use fragile code.

"I'm not ... trying to write a public site..."

<quote>
trying to write a public site using extra-fragile code.
</quote>

Which implies, to me, that it is a public site but you don't want
fragile code on it.

Not sure how much clearer I could have been. Maybe I should have put it up
at the top, to reduce the risk of bragging about standards compliance
awareness...

"This is for a private site...."

>Create a script block, set it's text property, and then appendChild it to
the document. Just remember that it suffers the same security restrictions
as cross-domain scripting. If both documents are yours, it isn't a
problem.

Your sample page, while generally studious, does not actually do anything to
the target page at load time. All it does is load the JS and demonstrate an
'alert()'. This does not prove the JS worked in the context of the target
browser.

It doesn't? The sample page (I assume you are actually referring to the
loadJSFile/ page) is a test page to see where different techniques work
(or fail) in different browsers. All of the results on that page are, to
the best of my knowledge, accurate. I did not do any of the Linux and
Mac testing so I depended on someone else for those results.

I'm not done researching all permutations (including a corroboration of your
createElement('script') technique at
http://www.dotvoid.com/view.php?id=13 ),

Not sure I totally agree with a few of the things on that page but most
of it seems to be precisely what I recommended you do.

but I have a most curious discrepancy between IE and Firefox to report.

That is always appreciated.

Here's the rig so far:

function evaluate(doc, sauce)
{
var s = doc.createElement('script');
s.text = sauce;
var head = doc.getElementsByTagName('head').item(0);

if (head)
{
head.appendChild(s);
return;
}
head = doc.head;
if (head)
{
head.appendChild(s);
return;
}
}
function update_grinder(sauce)
{
var grinder = $('grinder');

if (grinder)
{
var doc = grinder.contentDocument;
if (!doc) doc = grinder.document;
if (doc)
{
evaluate(doc, sauce);
return;
}
}
document.write("your browser sucks");
}

Now suppose the 'sauce' contained your favorite JS line in the whole world,
'Element.update("update_me", "here I B");'. And suppose both the outer and
inner HTML have a <span id='update_me'>. When I run that code....

I assume you are referring to some HTML that looks something like this:

<span id="update_me">some text or code<span id="update_me"></span></span>

Where you have multiple instances of the ID nested within one another.

What a browser does with invalid HTML is a guess. You could test it in
100 different browsers and you could possibly get 100 different results
(you wouldn't but it's possible) because ID attributes *must* be unique
in a document. It's the "garbage in garbage out" situation and to be
able to successfully script a document it behooves you to produce valid
HTML.

- IE updates the wrong $('update_me') - the one in the outer HTML

It updates the first one it encounters.

- only Firefox gets the context right and evaluates the inner HTML.

It updates the last one it encounters. Nest 8 of them and see if that
pattern holds true - it will.

Konqeror and Opera did nothing. Naturally, when I take out the outer
'update_me', IE just gives an error.

Without seeing a simple test page that demonstrates it nobody can do
anything but guess as to why.

I am open to the possibility of a bug in the $() inside of prototype.js,
which is where I will investigate next, but does that make Firefox the wrong one?

I would venture a pretty good guess that it isn't a bug in $() as all it
is is a wrapper function for getElementById and whether that is the
cause is easy to test. Replace $('ID') with
document.getElementById('ID') and test it again.

So it would seem your page tests alert() more thoroughly than it tests the
issues of javascript insertion...

No, it doesn't. The alert's that get produced (or don't) from the first
three buttons exists in an external file and the only way you get them
is if the browser supports that method. The alert could very well be
anything else I wanted it to be. It could insert HTML snippets in the
document somewhere (and I am actually considering changing it to do just
that).

The last 2 buttons create a dynamic script block and again the alert is
only a mechanism to show success. It could update a div/span in the
document to produce results.

The *only* way you get the alert is if the underlying mechanism to
create it is successful. If it isn't, then you don't get an alert.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #10

Phlip

Randy Webb whined:

>"I'm not ... trying to write a public site..."

<quote>
trying to write a public site using extra-fragile code.
</quote>

When a statement uses rhetorical ambiguity, rely on the first segment over
the second. I'm not trying to write a public site.

>Your sample page, while generally studious, does not actually do anything
to the target page at load time. All it does is load the JS and
demonstrate an 'alert()'. This does not prove the JS worked in the
context of the target browser.

It doesn't? The sample page (I assume you are actually referring to the
loadJSFile/ page) is a test page to see where different techniques work
(or fail) in different browsers. All of the results on that page are, to
the best of my knowledge, accurate. I did not do any of the Linux and Mac
testing so I depended on someone else for those results.

I need to inject JS across an iframe boundary. Your page is not about that.
I have lost count the number of times I clearly stated I am inserting from
one frame into another. Feel free to mis-quote again.

I assume you are referring to some HTML that looks something like this:

<span id="update_me">some text or code<span id="update_me"></span></span>

No. One span is in the hosting page and one is inside the iframe.

Where you have multiple instances of the ID nested within one another.

Why pretend you think anyone would do that? Except to allow you to continue
to drivel?

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #11

Randy Webb

Phlip babbled the following on 12/16/2006 10:58 AM:

Randy Webb whined:

<snip>

>>Your sample page, while generally studious, does not actually do anything
to the target page at load time. All it does is load the JS and
demonstrate an 'alert()'. This does not prove the JS worked in the
context of the target browser.
It doesn't? The sample page (I assume you are actually referring to the
loadJSFile/ page) is a test page to see where different techniques work
(or fail) in different browsers. All of the results on that page are, to
the best of my knowledge, accurate. I did not do any of the Linux and Mac
testing so I depended on someone else for those results.

I need to inject JS across an iframe boundary.

Then you rewrite loadJSFile so that instead of appending to the current
document you append it to the IFrame's document.

Your page is not about that.

True. Well, not directly but it covers the basics. It only leaves you to
figure out how to do it across an IFrame is all.

I have lost count the number of times I clearly stated I am inserting from
one frame into another. Feel free to mis-quote again.

No need to quote, I told you how to document.write across frames, I
assumed you would be able to realize how to do a script injection across
frames. Do you know how to script at all??

Just for you though, and Today only, here is a function for you:

function insertScriptTextAcrossFrames(frameID,scriptString) {
frameRef = window.frames[frameID]
var newScript = frameRef.document.createElement('script');
newScript.type = "text/javascript";
newScript.text = "alert('changeText worked')";
frameRef.document.getElementsByTagName('head')[0].appendChild(newScript);
}

And then call it:

insertScriptTextAcrossFrames('myIFrame','eval("You r mama")')
<snipped the whining babbling non-sense>

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #12

Randy Webb

Phlip said the following on 12/16/2006 10:58 AM:

Randy Webb whined:

>>"I'm not ... trying to write a public site..."
<quote>
trying to write a public site using extra-fragile code.
</quote>

When a statement uses rhetorical ambiguity, rely on the first segment over
the second. I'm not trying to write a public site.

That is not what you said, please make sure you write what you mean. It
will save you a lot of trouble.

Is your real name Thomas Lahn?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Dec 16 '06 #13

Phlip

Randy Webb wrote:

newScript.text = "alert('changeText worked')";

Alert doesn't use the context of the target object, like I already said. Try
updating a div in the target.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 16 '06 #14

John G Harris

In article <GI**************@newssvr19.news.prodigy.com>, Phlip
<ph******@yahoo.comwrites

<snip>

><span id="update_me">some text or code<span id="update_me"></span></span>

No. One span is in the hosting page and one is inside the iframe.

>Where you have multiple instances of the ID nested within one another.

Why pretend you think anyone would do that? Except to allow you to continue
to drivel?

The HTML 4 standard doesn't guarantee that you're allowed the same ID in
the two parts.

John
--
John Harris

Dec 16 '06 #15

Phlip

John G Harris wrote:

The HTML 4 standard doesn't guarantee that you're allowed the same ID in
the two parts.

I don't want to. The two IDs were to illustrate the bug. Without the second
SPAN with the same ID, I

The point, like I hinted in the subject line, was evaluating JS across a
frame boundary. So does HTML 4 say frames may happen to share the same IDs?
(I will make sure they don't anyway...)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 17 '06 #16

Phlip

>The HTML 4 standard doesn't guarantee that you're allowed the same ID in

>the two parts.

I don't want to. The two IDs were to illustrate the bug. Without the
second SPAN with the same ID, I

....get the same bug, with a different symptom; IE's JS throws an error
because it can't find the correct ID, which is right there...

The point, like I hinted in the subject line, was evaluating JS across a
frame boundary. So does HTML 4 say frames may happen to share the same
IDs? (I will make sure they don't anyway...)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Dec 17 '06 #17

foist javascript upon another frame

Similar topics