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

Dynamic IFRAME problem

P: n/a
using this example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>Test Page</title>

</head>

<body>

<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
var rnd = Math.ceil(Math.random()*10);
document.write(rnd);
if(rnd > 5){
document.write('<br><iframe src="http://www.yahoo.com"></iframe>');
}else{
document.write('<br><iframe src="http://www.google.com"></iframe>');
}
</SCRIPT>

</body>
</html>

This simple code writes an IFRAME element with a random src attribute
(Google , yahoo).
The code works fine over IE, but have a strange behavior on Fire Fox
1.5

It seems that the first src chosen is the dominate one and would not
replace it self when reloading the page (F5).

Any workaround?

Feb 20 '06 #1
Share this Question
Share on Google+
26 Replies


P: n/a
oops ... It seems that IE is doing the same scenario.

help?

Feb 20 '06 #2

P: n/a
here is an IE Workaround

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Test Page</title>
</head>
<body>
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
var rnd = Math.ceil(Math.random()*10);
document.write(rnd);
var f = document.createElement("iframe");
f.id = "frm"
document.body.appendChild(f)
if(rnd > 5){
document.getElementById("frm").src =
"http://www.google.com";
}else{
document.getElementById("frm").src = "http://www.yahoo.com";
}
</SCRIPT>
</body>
</html>

still dose not work on firefox

HELP

Feb 20 '06 #3

P: n/a
sh*************@gmail.com wrote:
using this example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
You should include the system identifier (URL of the DTD), Quirks Mode is
triggered otherwise:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
[...]
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
You can safely omit the `language' attribute, then declare HTML 4.01 Strict.
var rnd = Math.ceil(Math.random()*10);
document.write(rnd);
if(rnd > 5){
document.write('<br><iframe src="http://www.yahoo.com"></iframe>'); ^^ }else{
document.write('<br><iframe src="http://www.google.com"></iframe>'); ^^
ETAGO delimiters must be escaped in HTML `script' elements.
}
</SCRIPT>

</body>
</html>

This simple code writes an IFRAME element with a random src attribute
(Google , yahoo). The code works fine over IE, but have a strange
behavior on Fire Fox 1.5

It seems that the first src chosen is the dominate one
While I have been writing this, now I have read both your original posting
and your two followups. And the question occurred to me:

Do you really understand (the math of) random numbers?

The first branch should not be dominant. `rnd' can assume one of the
integer values 1 to 10 (because Math.random() returns IEEE-754 doubles x
from x = 0 to x < 1, and Math.ceil() returns the ceiling of its argument as
a IEEE-754 double). So the first condition is true iff `rnd' assumes one
of the values 6 to 10, that are 5 out of 10. Therefore, the statistical
probability of that event is 0.5 (or 50% or 1:2) as is the statistical
probability of the (opposite) event that `rnd' assumes one of the values 1
to 5.

However, probability is what can be observed only with a _large_ number of
repetitions of a random experiment. (This is the [Weak] Law of Large
Numbers that states, loosely speaking, that the relative frequency of an
event converges in a limit called the probability of that event as the
repetitions of the corresponding random experiment approach [positive]
infinity.)

So it is entirely possible (even though `rnd' is a computed random number
which differ from real random numbers), although not probable, that with
nine or nine hundred thousand repetitions of the experiment under the same
start conditions (in your case no-cache reloads, see below) the first
branch of the code is used each time, without violating this law.

The only reason why the probability of X=6..10 (X being the outcome of the
random experiment) could be greater than the probability of X=1..5 here is
that Math.random() could return 1 (which it should not according to
ECMAScript, but earlier Opera implementations are known for that). In that
case (X={1, 2, ..., 9, 10, ceil(1*10)}), the event X > 5 ({6, 7, 8, 9, 10,
10}) would occur with a probability of 6:11 and the opposite event (1 <= X
<= 5) would have to occur with a probability of only 5:11. However,
JavaScript (as implemented in Firefox) is not known to have this particular
bug in its Math.random() implementation.

That explained, you can simplify your little random experiment a lot:

var rnd = Math.random(); // still prone to the bug described above, though
// ...
if (rnd > 0.5)
{
// ...
}
else
{
// ...
}

Furthermore, you should not use consecutive calls of document.write.
Accumulate the strings to be written instead and write them once, e.g.

var rnd = Math.random(); // still prone to the bug described above, though

var a = [rnd, '<br>'];

if (rnd > 0.5){
a.push('<iframe src="http://www.yahoo.com"><\/iframe>');
}
else
{
a.push('<iframe src="http://www.google.com"><\/iframe>');
}

document.write(a.join(""));
and would not replace it self when reloading the page (F5).

Any workaround?


Ctrl+F5 or Ctrl+Shift+R, that overrides the browser cache.
PointedEars
Feb 20 '06 #4

P: n/a
hi Thomas, thanks for the fast reply.

All your remarks were contributing.
unfortunately the problem is more complex.

the main issue is that:

when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.

allow me to explain a scenario:

1) Lets say the page loads and the variable rnd is set to 1
2) The documet.write() is called with Google src IFRAME
3) All is good the Google frame is shown
4) F5 ... refreshing
6) the page loads and the variable rnd is set to 9
7) The documet.write() is called with Yahoo src IFRAME
8) ERROR the Google frame is displayed

furthermore if we write "javascript:alert(document.body.innerHTML)" in
the address bar we can see that the IFRAME src is set correctly and
still the browser displays the wrong frame.

Any New idea?
;-)

Feb 20 '06 #5

P: n/a
sh*************@gmail.com wrote:
[...]
when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.
As I said. And it is not cached in the browser DOM, but in
the browser cache :)
allow me to explain a scenario:

1) Lets say the page loads and the variable rnd is set to 1
2) The documet.write() is called with Google src IFRAME
3) All is good the Google frame is shown
4) F5 ... refreshing
As I said, if you refresh with F5 you use the browser cache;
with Ctrl+F5 or Ctrl+Shift+R you do not.
6) the page loads and the variable rnd is set to 9
7) The documet.write() is called with Yahoo src IFRAME
8) ERROR the Google frame is displayed
I observed the same behavior in

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060209
Debian/1.5.dfsg+1.5.0.1-2 Firefox/1.5.0.1

only that I also observed that when the first time the yahoo.com homepage
was displayed in the iframe, refresh with the F5 key resulted in displaying
yahoo.com even though rnd <= 5 (or <= 0.5; should have displayed the
google.com homepage).

It does not matter if the markup is Valid or not (escaping ETAGOs), if the
`language' attribute is used or not, if the document is rendered in Quirks
Mode or Standards Compliance Mode, if Math.ceil(Math.random() * 10) or
Math.random() is used, if document.write() is called one time or more
(although all of those /are/ valid concerns), if document.write() is used
or document.appendChild(). With Ctrl+R/F5 the previously generated
`iframe' element is used no matter the computed value of `rnd'.[1]

With overriding the browser cache as I described above and before,
this is not the case here. I am pretty sure it is the same with IE.

I have observed the same behavior in Gecko-based browsers (particularly
Mozilla/5.0 Navigator and Firefox) with the value of form controls before,
for example; with cached refresh (Ctrl+R or F5) they retain the changed
value, without using the cache (Ctrl+Shift+R or Ctrl+F5), they show the
initial value. Scripts are refreshed always nevertheless (this may be
due to default use of Cache-Control on my servers, though).
furthermore if we write "javascript:alert(document.body.innerHTML)" in
the address bar we can see that the IFRAME src is set correctly and
still the browser displays the wrong frame.
Apparently the `innerHTML' property partly does not use the browser cache.
Fascinating.
Any New idea?
;-)


No, the old one is still the solution to the problem. At least here.
HTH

PointedEars

P.S.: <URL:http://www.safalra.com/special/googlegroupsreply/>
___________
[1] And presumably just to show me that I understood statistical probability
properly, the Universe decided to give me a value greater than 0.5 eight
times in a row while was testing this <g/>
Feb 20 '06 #6

P: n/a
> when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.


You can avoid caching by appending an everchanging time to the URL of
the src.

Specifically:

document.getElementById("frm").src =
"http://www.google.com?ts' + (new Date()).getTime()

Ann

Feb 20 '06 #7

P: n/a
Giggle Girl wrote:
when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.


You can avoid caching by appending an everchanging time to the URL of
the src.

Specifically:

document.getElementById("frm").src =
"http://www.google.com?ts' + (new Date()).getTime()


What you are proposing means to access an `iframe' element that was created
and appended/included _before_ which is not the same thing as the OP tried.
With your approach, it would not even be necessary to "append an
everchanging time" (which would be a Bad Thing anyway).

Although I still do not understand why there is a problem at all (a cached
refresh is a /cached/ refresh) this approach (modifying the `iframe'
element afterwards) would lead to a solution. I would prefer to use the
`frames' collection then, though.
PointedEars
Feb 20 '06 #8

P: n/a
On Mon, 20 Feb 2006 20:39:48 +0200, Giggle Girl <mi*******@gmail.com>
wrote:
when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.


You can avoid caching by appending an everchanging time to the URL of
the src.

Specifically:

document.getElementById("frm").src =
"http://www.google.com?ts' + (new Date()).getTime()


Almost the same idea - the use of own cgi script, which then calls other
sites:

src="http://....some_script.cgi?site=http://www.google.com..."
Vladas
Feb 20 '06 #9

P: n/a
Vladas Saulis wrote:
[...] Giggle Girl [...] wrote:
when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.

You can avoid caching by appending an everchanging time to the URL of
the src.

Specifically:

document.getElementById("frm").src =
"http://www.google.com?ts' + (new Date()).getTime()


Almost the same idea - the use of own cgi script, which then calls other
sites:

src="http://....some_script.cgi?site=http://www.google.com..."


"Appending an everchanging time" was unnecessary already, now this is
complete overkill.
PointedEars
Feb 20 '06 #10

P: n/a
Thomas 'PointedEars' Lahn wrote:
Vladas Saulis wrote:
[...] Giggle Girl [...] wrote:
when writing the IFRAME dynamically (use example 1) the first "src" is
somehow cached in the browser DOM.
You can avoid caching by appending an everchanging time to the URL of
the src.

Specifically:

document.getElementById("frm").src =
"http://www.google.com?ts' + (new Date()).getTime()


Almost the same idea - the use of own cgi script, which then calls other
sites:

src="http://....some_script.cgi?site=http://www.google.com..."


"Appending an everchanging time" was unnecessary already, now this is
complete overkill.


Not only that. I will most certainly not work because the URL would still
be the same in the cache. Which is the difference to the former approach,
as the outcome of the client-side script code is not cached.
PointedEars
Feb 20 '06 #11

P: n/a
Thanks again for your help ... But the problem remains.

You see ... CTRL+F5 will not solve my problem, because the final code
will be on-line, and I cannot guarantee that the user will do so.
furthermore the problem remains even if navigating back and forward
between different URLs.(When returning to the page, the IFRAME will not
refresh).

I've Noticed (In IE) that when using document.body.appendChild() to
append an empty IFRAME, then changing it's src attribute by getting the
object with
document.getElementById() works fine.

But the problem in FireFox is still on (OH It's ON) ;-)

Any Creative Idea?

Feb 21 '06 #12

P: n/a
wrote on 21 feb 2006 in comp.lang.javascript:
Thanks again for your help ... But the problem remains.


What problem?

Please quote what you are replying to. This is usenet, not email.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at the
top of the article, then click on the "Reply" at the bottom of the article
headers. <http://www.safalra.com/special/googlegroupsreply/>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 21 '06 #13

P: n/a
OK I'll do it from now on ...

Problem :

"It seems that the first src chosen is the dominate one and would not
replace it self when reloading the page (F5). "

Please refer to the first post for more info.

Feb 21 '06 #14

P: n/a
wrote on 21 feb 2006 in comp.lang.javascript:
OK I'll do it from now on ...


What will you do from now on?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 21 '06 #15

P: n/a
Evertjan. wrote:
wrote on 21 feb 2006 in comp.lang.javascript:
OK I'll do it from now on ...


What will you do from now on?


Let's try to be productive.
here is a link for the entire thread on Google groups:

http://groups.google.co.uk/group/com...93eba8f5550c81

I've noticed that IE uses a cache mechanism for the IFRAMES using the
IFRAME location on the DOM.
So, If adding an element before the IFRAME when writing it to the DOM
the browser is forced to refresh it's content.

like so:

if(condition){
document.write("<iframe src='1'></iframe>")
}else{
document.write("<span style='display:none'></span><iframe
src='2'></iframe>")

}

unfortunately this is not the case on FireFox.

any idea? (beside trying to help me write better posts ;-))

Feb 21 '06 #16

P: n/a
VK

sh*************@gmail.com wrote:
I've noticed that IE uses a cache mechanism for the IFRAMES using the
IFRAME location on the DOM.
So, If adding an element before the IFRAME when writing it to the DOM
the browser is forced to refresh it's content.

like so:

if(condition){
document.write("<iframe src='1'></iframe>")
}else{
document.write("<span style='display:none'></span><iframe
src='2'></iframe>")

}

unfortunately this is not the case on FireFox.

any idea?


<body onload="setFrameContent()">
....
<iframe name="myFrame" width="500" height="300"
src="BlankPage.html"></iframe>
<noscript>
<p>
JavaScript is disabled.<br>
Please use these links to navigate manually:<br>
<a href="http://www.yahoo.com" target="myFrame">Yahoo!</a><br>
<!-- feel free to beautify this HTML in the needed way -->
</p>
</noscript>
....

function setFrameContent() {
var url = getRandomURL();
var frm = document.frames['myFrame'];
frm.src = url;
}

Feb 21 '06 #17

P: n/a
sh*************@gmail.com wrote:
Thanks again for your help ... But the problem remains.
Your problem of still not being able to quote properly? Certainly :-(
You see ... CTRL+F5 will not solve my problem, because the final code
will be on-line, and I cannot guarantee that the user will do so.
So do not use client-side scripting to generate this `iframe' element.
Generate it server-side and use cache control headers.
furthermore the problem remains even if navigating back and forward
between different URLs.(When returning to the page, the IFRAME will not
refresh).


This is the user's expectation, and there is no way to change this browser
behavior.
PointedEars
Feb 21 '06 #18

P: n/a
wrote on 21 feb 2006 in comp.lang.javascript:
if(condition){
document.write("<iframe src='1'></iframe>")
}else{
document.write("<span style='display:none'></span><iframe
src='2'></iframe>")

}

unfortunately this is not the case on FireFox.

any idea? (beside trying to help me write better posts ;-))


Why not just reload the iframe?

<iframe src='dummy.html' id='ifr'></iframe>

document.getElementById('ifr').src =
(condition) ? 'page1.html' : 'page2.html'
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 21 '06 #19

P: n/a
Evertjan. wrote:
wrote on 21 feb 2006 in comp.lang.javascript:
if(condition){
document.write("<iframe src='1'></iframe>")
}else{
document.write("<span style='display:none'></span><iframe
src='2'></iframe>")

}

unfortunately this is not the case on FireFox.

any idea? (beside trying to help me write better posts ;-))


Why not just reload the iframe?

OK ... Here is the deal: I need to integrate my code with an external
script.
The external script is using document.write(<iframe...)

and my script should decide if to write the external script..

document.write("<script...>") (which writes an Iframe element)
OR
write my Iframe

document.write("<iframe...")

so I need to stick with this logic. The example I used in my first post
was just in purpose of simplifying the problem.

my conclusions so far:
IE uses a cache mechanism according to the IFRAME position in the DOM,
so when adding an element before the iframe the problem is solved.

I'm still trying to find a workaround for FireFox that will allow me to
use the document.write method, I'll be sure to Post any new
revelations.

thanks again!!!!!!!!

Feb 21 '06 #20

P: n/a
sh*************@gmail.com wrote:
[...] I need to integrate my code with an external script.
The external script is using document.write(<iframe...)

and my script should decide if to write the external script..

document.write("<script...>") (which writes an Iframe element)
This is almost always nonsense. Why do you not include the generated
`script' element in the first place?
OR
write my Iframe

document.write("<iframe...")

so I need to stick with this logic. [...]


No, you don't. As Ann (Giggle Girl) pointed out already, you can modify the
`iframe' element generated by the "external script" afterwards. Which
should be reliable on cached reload in contrast to your efforts of cheating
the cache somehow.

<head>
...
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function modifySrc()
{
if (typeof window != "undefined"
&& window.frames
&& window.frames[0]
&& Math.random() > 0.5)
{
window.frames[0].src = "http://www.yahoo.com/";
}
}
</script>
</head>

<body onload="modifySrc()">
...
<!-- "external script" that generates an
iframe[src="http://www.google.com/"] element;
let it be the only one here for simplicity of
the example -->
<script src="..." type="text/javascript"></script>
...
</body>
PointedEars
Feb 21 '06 #21

P: n/a

Thomas 'PointedEars' Lahn wrote:
sh*************@gmail.com wrote:
[...] I need to integrate my code with an external script.
The external script is using document.write(<iframe...)

and my script should decide if to write the external script..

document.write("<script...>") (which writes an Iframe element)


This is almost always nonsense. Why do you not include the generated
`script' element in the first place?
OR
write my Iframe

document.write("<iframe...")

so I need to stick with this logic. [...]


No, you don't. As Ann (Giggle Girl) pointed out already, you can modify the
`iframe' element generated by the "external script" afterwards. Which
should be reliable on cached reload in contrast to your efforts of cheating
the cache somehow.

<head>
...
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function modifySrc()
{
if (typeof window != "undefined"
&& window.frames
&& window.frames[0]
&& Math.random() > 0.5)
{
window.frames[0].src = "http://www.yahoo.com/";
}
}
</script>
</head>

<body onload="modifySrc()">
...
<!-- "external script" that generates an
iframe[src="http://www.google.com/"] element;
let it be the only one here for simplicity of
the example -->
<script src="..." type="text/javascript"></script>
...
</body>
PointedEars


There is a fundamental error in this flow.
If the script is "Hard-coded" to the body the result would be like so:

Lets say an ad is displaying in the "script iframe"
the page loads and writes the "Script Iframe" therefore creating a
"server hit" to the ad publisher, resolving with a cache request (I
mean money) for their service...
then the page loads and the iframe src is changed to my page.

the correct flow would be to load the correct Iframe from the beginning

Feb 21 '06 #22

P: n/a
sh*************@gmail.com wrote:
Thomas 'PointedEars' Lahn wrote:
sh*************@gmail.com wrote:
[...]
No, you don't. As Ann (Giggle Girl) pointed out already, you can modify
the `iframe' element generated by the "external script" afterwards.
Which should be reliable on cached reload in contrast to your efforts of
cheating the cache somehow.

<head>
...
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function modifySrc()
{
if (typeof window != "undefined"
&& window.frames
&& window.frames[0]
&& Math.random() > 0.5)
{
window.frames[0].src = "http://www.yahoo.com/";
}
}
</script>
</head>

<body onload="modifySrc()">
...
<!-- "external script" that generates an
iframe[src="http://www.google.com/"] element;
let it be the only one here for simplicity of
the example -->
<script src="..." type="text/javascript"></script>
...
</body>
[...]
There is a fundamental error in this flow.


There is not. Obviously you have not even tried it.
If the script is "Hard-coded" to the body the result would be like so:
No, it will not be empty if client-side scripting is supported.

And if client-side scripting is not supported, your
document.write('<script ...') would not work anyway.
Lets say an ad is displaying in the "script iframe"
the page loads and writes the "Script Iframe" therefore creating a
"server hit" to the ad publisher, resolving with a cache request (I
mean money) for their service...
The `script' element that triggers the external script creates the
"server hit" whether it is generated dynamically or not.
the correct flow would be to load the correct Iframe from the beginning


To be blunt, you are not qualified to label something as correct regarding
client-side scripting.

Unless you learn to quote eventually, this will be my last response to
one of your postings.
PointedEars
Feb 21 '06 #23

P: n/a
Thomas ... don't bother... It's all clear to me after reading this post

http://www.thescripts.com/forum/thread150264.html

Here is a quote for you:

"ralf: Please ignore Thomas, we are trying to get him through puberty
but
until we manage to survive those hectic days in his life, he continues
to ramble incoherently about attribution novels without having a clue
what he is talking about. Until we can manage to either train him,
educate him, or eradicate him, ignore his babbling about attributions."

Feb 21 '06 #24

P: n/a
sh*************@gmail.com wrote:
Thomas ... don't bother...


I won't with your postings anymore. *PLONK*
Feb 21 '06 #25

P: n/a
JRS: In article <26*****************@PointedEars.de>, dated Mon, 20 Feb
2006 16:45:30 remote, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <Po*********@web.de> posted :

Furthermore, you should not use consecutive calls of document.write.
No reason here to avoid that. Code should be written to be
comprehensible to its author and maintainers. Any extra time taken by
document.write will here be negligible in comparison with the time taken
in dealing with the http:// references.

However, one should look for ways to reduce repetitiveness in code.
Accumulate the strings to be written instead and write them once, e.g.

var rnd = Math.random(); // still prone to the bug described above, though

var a = [rnd, '<br>'];

if (rnd > 0.5){
a.push('<iframe src="http://www.yahoo.com"><\/iframe>');
}
else
{
a.push('<iframe src="http://www.google.com"><\/iframe>');
}

document.write(a.join(""));


OP : use something like

var rnd = Math.random();
document.write('<iframe src="http://www.' +
(rnd>=0.5?'google':'yahoo') +
'.com"><\/iframe>');

or

document.write('<iframe src="http://www.' +
(Math.random()>=0.5?'google':'yahoo') +
'.com"><\/iframe>');

--
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.
Feb 21 '06 #26

P: n/a
Dr John Stockton wrote:
[...] Thomas 'PointedEars' Lahn [...] posted :
Furthermore, you should not use consecutive calls of document.write.


No reason here to avoid that. [...]


The reason is that it is error-prone. Examples and more detailed
explanations have been posted before.
Accumulate the strings to be written instead and write them once, e.g.

var rnd = Math.random(); // still prone to the bug described above,
though

var a = [rnd, '<br>'];

if (rnd > 0.5){
a.push('<iframe src="http://www.yahoo.com"><\/iframe>');
}
else
{
a.push('<iframe src="http://www.google.com"><\/iframe>');
}

document.write(a.join(""));


OP : use something like

var rnd = Math.random();
document.write('<iframe src="http://www.' +
(rnd>=0.5?'google':'yahoo') +
'.com"><\/iframe>');

or

document.write('<iframe src="http://www.' +
(Math.random()>=0.5?'google':'yahoo') +
'.com"><\/iframe>');


I am afraid that this probably more efficient, but also more complicated
code does not qualify as a solution to the "cached reload" problem of the
OP either.
PointedEars
Feb 21 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.