Window and iframe question

Don Li

unread,

Mar 21, 2008, 3:13:57 PM3/21/08

to

Hi,

Can I rewrite the following statement
window.frames.frm1.document.designMode = "On";
with
window["BusinessNews"].frames.notes#currentrow#.document.designMode =
"On";
// where BusinessNews is a named window
?

Also, all the {iframes} are inside a DIV. So, put it another way,
how to reference frames's {childern} within a DIV?

Thanks.

Thomas 'PointedEars' Lahn

unread,

Mar 21, 2008, 3:25:47 PM3/21/08

to

Don Li wrote:
> Can I rewrite the following statement
> window.frames.frm1.document.designMode = "On";
> with
> window["BusinessNews"].frames.notes#currentrow#.document.designMode =
> "On";
> // where BusinessNews is a named window
> ?

No, there is no built-in registry of Window objects. You can use the mere
name of a window to refer to it --

window.open("...", "BusinessNews").frames["notes"]...

--, but that causes the document of the window in question to be reloaded.
You have to store a reference *first*, and use it later (that's a FAQ, I
presume):

var w = window.open(...);
...
w.frames["notes"]...

As you have been told repeatedly already, (your) server-side code is
irrelevant to client-side problems such as this. Please stop posting it then.

> Also, all the {iframes} are inside a DIV. So, put it another way,
> how to reference frames's {childern} within a DIV?

It does not matter that the `iframe' elements are descendents of a `div'
element, their respective element objects are referenced by items of the
`frames' collection and can be referenced through it.

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Don Li

unread,

Mar 21, 2008, 4:34:49 PM3/21/08

to

> --, but that causes the document of the window in question to be reloaded.
> You have to store a reference *first*, and use it later (that's a FAQ, I
> presume):
>
> var w = window.open(...);
> ...
> w.frames["notes"]...
>

An existing process has already open such a window at top level. What
I tried to do with your technique above was to set a var reference,
var win = window.open("about:Tabs","BusinessNews");

Then at the second level, when this "BusinessNews is already open,
tried to reference the window and set designMode to be "on" for the
frm1 iframe,
win.frames.frm1.document.designMode = "On";
It did not work. What did I do wrong?

Don Li

unread,

Mar 21, 2008, 4:41:40 PM3/21/08

to

On Mar 21, 4:34 pm, Don Li <tatata9...@gmail.com> wrote:
> > --, but that causes the document of the window in question to be reloaded.
> > You have to store a reference *first*, and use it later (that's a FAQ, I
> > presume):
>
> > var w = window.open(...);
> > ...
> > w.frames["notes"]...
>

> An existing process has already open such a window at top level. What
> I tried to do with your technique above was to set a var reference,
> var win = window.open("about:Tabs","BusinessNews");

I'm suspicious of the above, the window is going to be open by a
process at the top level already,
// can I can't do anything about this process other than knowing the
window's name

then, this set

var win = window.open("about:Tabs","BusinessNews");

statement is either illogical or wrong, no? Didn't work anyway.

Thomas 'PointedEars' Lahn

unread,

Mar 21, 2008, 5:10:36 PM3/21/08

to

Don Li wrote:
> On Mar 21, 4:34 pm, Don Li <tatata9...@gmail.com> wrote:
>>> --, but that causes the document of the window in question to be reloaded.
>>> You have to store a reference *first*, and use it later (that's a FAQ, I
>>> presume):
>>> var w = window.open(...);
>>> ...
>>> w.frames["notes"]...
>
>> An existing process has already open such a window at top level.

What are you talking about?

>> What I tried to do with your technique above was to set a var reference,
>> var win = window.open("about:Tabs","BusinessNews");
> I'm suspicious of the above, the window is going to be open by a
> process at the top level already,
> // can I can't do anything about this process other than knowing the
> window's name
>
> then, this set
> var win = window.open("about:Tabs","BusinessNews");
> statement is either illogical or wrong, no?

Who knows.

> Didn't work anyway.

http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork

Is there a user agent where about:Tabs is a valid URI anyway?

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Don Li

unread,

Mar 21, 2008, 6:10:12 PM3/21/08

to

On Mar 21, 5:10 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Don Li wrote:
> > On Mar 21, 4:34 pm, Don Li <tatata9...@gmail.com> wrote:
> >>> --, but that causes the document of the window in question to be reloaded.
> >>> You have to store a reference *first*, and use it later (that's a FAQ, I
> >>> presume):
> >>> var w = window.open(...);
> >>> ...
> >>> w.frames["notes"]...
>
> >> An existing process has already open such a window at top level.
>
> What are you talking about?

Ok, let me cite a use case,
<cfwindow name="pubSector" ... />
that creates a DIV, so I was told...
then my dynamically created IFRAMES are within that DIV, and I need a
way to reference them.

>
> >> What I tried to do with your technique above was to set a var reference,
> >> var win = window.open("about:Tabs","BusinessNews");
> > I'm suspicious of the above, the window is going to be open by a
> > process at the top level already,
> > // can I can't do anything about this process other than knowing the
> > window's name
>
> > then, this set
> > var win = window.open("about:Tabs","BusinessNews");
> > statement is either illogical or wrong, no?
>
> Who knows.

I tried, it didn't work.

>
> > Didn't work anyway.
>
> http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork
>
> Is there a user agent where about:Tabs is a valid URI anyway?

When one opens up IE7, it defaults to "about:Tabs" in the URL address
space, hence, one may interprete it as a URI.

Thomas 'PointedEars' Lahn

unread,

Mar 21, 2008, 6:20:17 PM3/21/08

to

Don Li wrote:

> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Don Li wrote:
>>> On Mar 21, 4:34 pm, Don Li <tatata9...@gmail.com> wrote:
>>>>> --, but that causes the document of the window in question to be reloaded.
>>>>> You have to store a reference *first*, and use it later (that's a FAQ, I
>>>>> presume):
>>>>> var w = window.open(...);
>>>>> ...
>>>>> w.frames["notes"]...
>>>> An existing process has already open such a window at top level.
>> What are you talking about?
> Ok, let me cite a use case,
> <cfwindow name="pubSector" ... />
> that creates a DIV, so I was told...

For the last time, your server-side code is irrelevant to this problem. And
I am afraid you will not accomplish anything if you continue depending on
hearsay. Use the Source, Luke. It is *there*, in View menu, Source item,
for example.

> then my dynamically created IFRAMES are within that DIV, and I need a
> way to reference them.

You have been told already.

>>>> What I tried to do with your technique above was to set a var reference,
>>>> var win = window.open("about:Tabs","BusinessNews");
>>> I'm suspicious of the above, the window is going to be open by a
>>> process at the top level already,
>>> // can I can't do anything about this process other than knowing the
>>> window's name
>>> then, this set
>>> var win = window.open("about:Tabs","BusinessNews");
>>> statement is either illogical or wrong, no?
>> Who knows.
> I tried, it didn't work.

That does not necessarily mean that it is illogical or wrong.

>>> Didn't work anyway.
>> http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork
>>
>> Is there a user agent where about:Tabs is a valid URI anyway?
> When one opens up IE7, it defaults to "about:Tabs" in the URL address
> space, hence, one may interprete it as a URI.

It is a URI, per RFC 3986. Whether it is a valid one for the task to be
accomplished is another matter. Why not begin with testing an empty URI
reference instead?

> [my signature]

For the last time, please stop full-quoting.

Score adjusted

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Don Li

unread,

Mar 21, 2008, 6:43:59 PM3/21/08

to

> It is a URI, per RFC 3986. Whether it is a valid one for the task to be
> accomplished is another matter. Why not begin with testing an empty URI
> reference instead?

That was my first attempt;
var win = window.open("","BusinessNews");
The second time, I used

var win = window.open("about:Tabs","BusinessNews");

And of course, I do view source code from my browser... zillions of js
code generated by the package(not my code) mashed up with html code
make them unreadable...

Logos

unread,

Mar 22, 2008, 8:49:41 AM3/22/08

to

PointedEars is absolutely correct here, Don. You can't post your
serverside code and expect people to be able to offer you advice - you
have to post the code that is generated and that you can see when you
view source in the browser. Knowing what the server side code is
doesn't tell anyone jackola about what is actually output by that
code.

If you can't read your own code's output, then how do you expect
others to? I'm afraid the ugly answer is, is that you need to either
clean up your code or use a different tool to generate it... (in my
opinion ColdFusion is only one step above Frontpage - a toy, not a dev
tool! :P)

Good luck with your issue, and with learning what is actually going on
with the code you're producing!

Tyler

Don Li

unread,

Mar 22, 2008, 1:13:13 PM3/22/08

to

On Mar 22, 8:49 am, Logos <tyler.st...@gmail.com> wrote:
> PointedEars is absolutely correct here, Don. You can't post your
> serverside code and expect people to be able to offer you advice - you
> have to post the code that is generated and that you can see when you
> view source in the browser. Knowing what the server side code is
> doesn't tell anyone jackola about what is actually output by that
> code.
>
> If you can't read your own code's output, then how do you expect
> others to? I'm afraid the ugly answer is, is that you need to either
> clean up your code or use a different tool to generate it... (in my
> opinion ColdFusion is only one step above Frontpage - a toy, not a dev
> tool! :P)
>
> Good luck with your issue, and with learning what is actually going on
> with the code you're producing!
>
> Tyler

Tyler,

Cold Fusion 8 uses lots of open source javascript packages including
Ext, YUI etc. hence, the page in question loading tons of javascript
code from these freebies, hence, it did not make sense to copy over
and paste zillion line of these js code here... but points well taken
and you guys are absolutely right. FF's extension Firebug seems a
great debugging tool, with it, now I've identified some problems.

New Attempt Background Info:
a) I've now added HTML and its end tag to wrap each instance of data
set in the output;
though it's against logic because this section is already inside
HTML tag, but oh well...
b) Added javascript definitions and references in the HEAD section for
each iframe that each instance of data would work with.

// Editor1 is for iframe content interface with a WYSIWG js function
Editor1 = document.getElementById('iframe1').contentWindow.document;
/* seems ok */

// set data value
var s1 = 'dynamic data set';
// set value for the hidden field named text1
document.getElementById('text1').value = s1;
/* seems ok */

// populate each iframe src
var D = window.frames['iframe1'].document;
D.open();
D.write('<html>' + s1 + '</html>');
D.close();
/* not working, not sure why */

Many thanks.

Don

VK

unread,

Mar 22, 2008, 1:45:29 PM3/22/08

to

On Mar 22, 8:13 pm, Don Li <tatata9...@gmail.com> wrote:
> // populate each iframe src
> var D = window.frames['iframe1'].document;
> D.open();
> D.write('<html>' + s1 + '</html>');
> D.close();
> /* not working, not sure why */

Because your script gets broken somewhere before this point: check
Tools > Error Console in Firefox for error messages.

It also can be a security block, the most common errors of this kind
are:
1) The initial iframe src loads a page from another domain OR from
another subdomain of the same domain - neither is allowed for
scripting later.
2) The initial iframe src is set to "" (empty string) or not set at
all - neither is allowed for scripting later.
3) The initial iframe src is set to "about:blank" or some other
internal page - neither is allowed for scripting later with higher
security settings.

So check that each involved iframe has src attribute set to some
_real_ page in the same subdomain of your domain as the page itself.
Any site using (i)frames has for such purpose some minimalistic
blank.html page without any content and with the background-color
matching the color of the main page, something like
<html><body bgcolor="#FFFFFF"></body></html>
If you don't have such page yet then make it now - and of course you
don't have to name it "blank.html", name it any way you want. From now
one take a habit to always point to this page for all your dynamic
(i)frames and enjoy a much more peaceful life :-)

P.S. A working demo - Untitled1.html assumed to be in the same
directory where this page is:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en-US">
<head>
<meta http-equiv="Content-type"
content="text/html; charset=iso-8859-1">
<title>Demo</title>
<script type="text/javascript">

function init() {
var doc = self.frames['out'].document;
if ('designMode' in doc) {
//self.frames['out'].document.designMode = 'on';
}
doc.clear();
doc.open('text/html','replace');
doc.write('<html><body>Hello!</body></html>');
doc.close();
}

function releaseContextAndInit() {
window.setTimeout('init()',10);
}
window.onload = releaseContextAndInit;
</script>
</head>
<body>
<h1>Demo</h1>
<iframe name="out" src="Untitled1.html"
contenteditable="true"></iframe>
</body>
</html>

Don Li

unread,

Mar 22, 2008, 2:53:37 PM3/22/08

to

On Mar 22, 1:45 pm, VK <schools_r...@yahoo.com> wrote:
> ...

> function releaseContextAndInit() {
> window.setTimeout('init()',10);}
>
> window.onload = releaseContextAndInit;
> </script>
> </head>
> <body>
> <h1>Demo</h1>
> <iframe name="out" src="Untitled1.html"
> contenteditable="true"></iframe>
> </body>
> </html>

Sorry my problem statement wasn't clear enough. The page would have
multiple iframes, the src of each of them would be populated with data
set from a db table, not some existinig html file(s).

VK

unread,

Mar 22, 2008, 3:05:49 PM3/22/08

to

On Mar 22, 9:53 pm, Don Li <tatata9...@gmail.com> wrote:
> Sorry my problem statement wasn't clear enough. The page would have
> multiple iframes, the src of each of them would be populated with data
> set from a db table, not some existinig html file(s).

Please take a look at the code I posted and my comments. I do
understand very clear what you are trying to achieve. Your iframes can
have any content your want right after the page is loaded. But in the
HTML source they have to have src attribute set to a real HTML file or
the bird won't fly:
...
<iframe name="out1" src="blank.html></iframe>
<iframe name="out2" src="blank.html></iframe>
<iframe name="out3" src="blank.html></iframe>
...
<iframe name="out33" src="blank.html></iframe>
...

NOW you can use your script to populate your iframes with any content
you want. And the most common mistake I was mentioning is something
like:
<iframe name="out1"></iframe>
or
<iframe name="out1" src=""></iframe>
"because there is not any initial page in my solution" - and it just
doesn't work this way.

Study my sample I have posted, you can uncomment

//self.frames['out'].document.designMode = 'on';

as well: it doesn't matter.

Don Li

unread,

Mar 22, 2008, 5:05:52 PM3/22/08

to

Thank you. I tried your sample twice.
a) when loaded from a web server, it loaded data into the iframe,
however, not editable;
b) opened it as a file, IE7 blocked it and ask for permission, after
granting it then loaded data into the iframe, however, not editable;
So, I think you're exactly right it's related security issue, but why
with the same security setting, another WYSIWYG editor can load data
and allow editing and so forth?

VK

unread,

Mar 22, 2008, 5:48:16 PM3/22/08

to

In this particular case it is most probably either copy-and-past error
from your side or some other script block interference:

http://www.geocities.com/schools_ring/tmp/editable.html

works just fine for me for both Firefox and IE. The only change I have
made against of what I already posted is splitting tags in
document.write:
doc.write('<ht'+'ml><bod'+'y>Hello!</b'+'ody></h'+'tml>')
It is absolutely irrelevant to the subject, it is just to prevent
Yahoo! from inserting their HTML crap right into middle of the script
so breaking it.

Don Li

unread,

Mar 22, 2008, 7:23:40 PM3/22/08

to

> > Thank you. I tried your sample twice.
> > a) when loaded from a web server, it loaded data into the iframe,
> > however, not editable;
> > b) opened it as a file, IE7 blocked it and ask for permission, after
> > granting it then loaded data into the iframe, however, not editable;
> > So, I think you're exactly right it's related security issue
>
> In this particular case it is most probably either copy-and-past error
> from your side or some other script block interference:
>
> http://www.geocities.com/schools_ring/tmp/editable.html
>
> works just fine for me for both Firefox and IE. The only change I have
> made against of what I already posted is splitting tags in
> document.write:
> doc.write('<ht'+'ml><bod'+'y>Hello!</b'+'ody></h'+'tml>')
> It is absolutely irrelevant to the subject, it is just to prevent
> Yahoo! from inserting their HTML crap right into middle of the script

> so breaking it.- Hide quoted text -
>
> - Show quoted text -

Your link works. The technique of setting iframe.src = 'a dynamic
data set' also works as simple page (tested with IE7). The thing that
is killing me is that, when I embed the javascript code inside the
middle of an appliation page it failed to be called/executed. I
understand the standard way to add js functions is to place them in
the HTML head section, however, I have to bypass this rule for this
case. Also, some one even suggested to place js the bottom of a page,
which seems to suggest, js can be anywhere and I use inline short js
command in the middle of nowhere all the time.

From the execution block of your code and such difficulty I encounter
(which shouldn't), I tend to draw a conclusion that some javascript
kitty might be messing around my box, what do you think?

Thanks.

VK

unread,

Mar 23, 2008, 1:58:54 PM3/23/08

to

On Mar 23, 2:23 am, Don Li <tatata9...@gmail.com> wrote:
> Your link works. The technique of setting iframe.src = 'a dynamic
> data set' also works as simple page (tested with IE7). The thing that
> is killing me is that, when I embed the javascript code inside the
> middle of an appliation page it failed to be called/executed. I
> understand the standard way to add js functions is to place them in
> the HTML head section, however, I have to bypass this rule for this
> case.

There are some rules we have to bypass sometimes to get the things
done: and there are some rules that cannot be bypassed because it is
just not technically possible. It is hard to add anything valuable
without seeing a minimum output HTML still demonstrating your problem.

Don Li

unread,

Mar 23, 2008, 4:12:40 PM3/23/08

to

On Mar 23, 1:58 pm, VK <schools_r...@yahoo.com> wrote:
>
> There are some rules we have to bypass sometimes to get the things
> done: and there are some rules that cannot be bypassed because it is
> just not technically possible. It is hard to add anything valuable
> without seeing a minimum output HTML still demonstrating your problem.

Thank you very much. This 'beast' (forgive me for the language), is
part of Ext open source stuff... (not complaining).

Following is the rendered code (and I've marked "PROBLEM AREA" as my
speculation of culprit close to the bottom). I'm indebted to you and
I've tried and also commented out your

"
function releaseContextAndInit() {
window.setTimeout('init()',10);
}
window.onload = releaseContextAndInit;
"

code, I think I understand why you wrote that...

<html xmlns="http://www.w3.org/1999/xhtml">
<head><script type="text/javascript">_cf_loadingtexthtml="<div
align='center'><img src='/resources/cf/images/loading.gif'/>";
_cf_contextpath="";
_cf_ajaxscriptsrc="/CFIDE/scripts/ajax";
_cf_jsonprefix='//';
_cf_clientid='8CB7C279BB2DF5C9898043CD52062AD3';</script><script
type="text/javascript" src="/ajax/messages/cfmessage.js"></script>
<script type="text/javascript" src="/scripts/ajax/package/cfajax.js"></
script>
<script type="text/javascript" src="/scripts/ajax/yui/yahoo-dom-event/
yahoo-dom-event.js"></script>
<script type="text/javascript" src="/scripts/ajax/yui/animation/
animation-min.js"></script>
<script type="text/javascript" src="/scripts/ajax/ext/adapter/yui/ext-
yui-adapter.js"></script>
<script type="text/javascript" src="/scripts/ajax/ext/ext-core.js"></
script>
<script type="text/javascript" src="/scripts/ajax/ext/package/
resizable.js"></script>

<title>XYZ</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<meta name="keywords" content="XYZ">
<meta name="description" content="XYZ">
<script language="JavaScript" src="/Speller.js"></script>
<style type="text/css">
#projectautosuggest {
z-index:10;
}
</style>
<link rel="stylesheet" type="text/css" href="/scripts/ajax/resources/
ext/css/ext-all.css" />
<link rel="stylesheet" type="text/css" href="/scripts/ajax/resources/
cf/cf.css" />
<link rel="stylesheet" type="text/css" href="/scripts/ajax/resources/
yui/yui.css" />

</script>

</div>
</div> <div id="cf_window1206302048159" class="yuiextdlg">

</div>
</div> <div id="cf_window1206302048161" class="yuiextdlg">

// PROBLEM AREA starts
<div id="cf_window1206302048167" class="yuiextdlg">

</div>

</div>
// PROBLEM AREA ends

</body>
</html>

VK

unread,

Mar 23, 2008, 5:56:02 PM3/23/08

to

Holly mother of Lord! I just love those corporate Frankenstein style
solutions. The only difference is that the resulting walking dead is
made not by one but by a whole set of mad doctors. :-)
I just hope that you are getting a sufficient pay for digging in this
mess. :-)

Yes, but the problem area contains just one styled DIV with two nested
styled DIV in it. There are not any IFRAME here. Is it supposed to be
added later by some script block?

Don Li

unread,

Mar 23, 2008, 6:36:06 PM3/23/08

to

>
> > // PROBLEM AREA starts
> > <div id="cf_window1206302048167" class="yuiextdlg">
>
> > <div id="myMAIN_title" class="x-dlg-hd" style="background-
> > color:#BDD3FF;color:#FFFFFF;">
> > XYZ
> > </div>
> > <div id="myMAIN_body" class="x-dlg-bd">
>
> > </div>
>
> > </div>
> > // PROBLEM AREA ends
>
> > </body>
> > </html>
>
> Yes, but the problem area contains just one styled DIV with two nested
> styled DIV in it. There are not any IFRAME here. Is it supposed to be

> added later by some script block?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

Sorry for lack of clarity. The <PROBLEM AREA/> is supposed to entail
the following test code:
--------------------------------
main page
<form id="nutsFrm" method="post">
<iframe name="out" id="out" src="Untitled1.html"
contenteditable="true" style="width:300px; height:150px"></iframe><br/
>
</form>

<form id="nutsFrm2" method="post">
<iframe name="nuts2" id="nuts2" style="width:300px; height:150px"></
iframe><br/>
</form>
--------------------------------

If I use simple other language's equivalent of "include" then it would
work (both your method and mine), however, it would LOSE the benefit
of very impressive presentation that is provided by a specific
function called CFWINDOW here (this app is literally sits inside it).
Hence, I'm caught in a very difficult situation...

Now a related question, other than setting iframe's designMode to
"On", is there another way that would allow similar function, that is,
WYSIWYG editing?

Many thanks.

Logos

unread,

Mar 24, 2008, 10:21:17 AM3/24/08

to

On Mar 22, 10:13 am, Don Li <tatata9...@gmail.com> wrote:
> On Mar 22, 8:49 am, Logos <tyler.st...@gmail.com> wrote:
>
>
>
> > PointedEars is absolutely correct here, Don. You can't post your
> > serverside code and expect people to be able to offer you advice - you
> > have to post the code that is generated and that you can see when you
> > view source in the browser. Knowing what the server side code is
> > doesn't tell anyone jackola about what is actually output by that
> > code.
>
> > If you can't read your own code's output, then how do you expect
> > others to? I'm afraid the ugly answer is, is that you need to either
> > clean up your code or use a different tool to generate it... (in my
> > opinion ColdFusion is only one step above Frontpage - a toy, not a dev
> > tool! :P)
>
> > Good luck with your issue, and with learning what is actually going on
> > with the code you're producing!
>
> > Tyler
>
> Tyler,
>
> Cold Fusion 8 uses lots of open source javascript packages including
> Ext, YUI etc. hence, the page in question loading tons of javascript
> code from these freebies, hence, it did not make sense to copy over
> and paste zillion line of these js code here... but points well taken
> and you guys are absolutely right. FF's extension Firebug seems a
> great debugging tool, with it, now I've identified some problems.

The web developer toolbar and aardvark are also godsends - you might
want to snag them if you aren't using them already.

Just as an FYI, if you need to post tons of code it's often handy to
put up a dummy page on your server somewhere and post a link to it (I
do that, anyway, and *I* think it's handy!)

Logos

unread,

Mar 24, 2008, 10:24:47 AM3/24/08

to

Are the functions you're including in the HTML block straight code
between <script> tags, or is it a link to an exterior file? If the
former, than I am puzzled. If the latter, the files won't load
properly if you place links to them in the body.

Tyler

Don Li

unread,

Mar 24, 2008, 2:21:49 PM3/24/08

to

Tyler,

Please see my comments below. Thanks.

Don

>
> Are the functions you're including in the HTML block straight code
> between <script> tags, or is it a link to an exterior file?

Sorry I don't understand very clearly of your above question. Are you
saying? Does the "top code" include plain HTML code or something else
like lots of javascripts?

then your "bottom code" ...?

If we're on the same page with this, then, the "top code" includes
tons of open source javascripts.

Now, here's another fact, with the same code structure/layout,
FckEditor, works. The problem I have with it is that it's way too
bloated for my need (I only need 5 to 7ish editing features), why
should I load its 523 files spanning across 72 folders (nuts for
efficiency if you ask me). And this editor slows down my app by more
than 50% (probably the editor would fit others' need though).

Thanks.

Don
P.S.
On your "if you need to post tons of code it's often handy to

put up a dummy page on your server somewhere and post a link to it (I
do that, anyway, and *I* think it's handy!)

My app is in beta, I don't feel comfortable to release its root IP
address (security concern is one thing, before release I'll beef up
security as well...)

>If the
> former, than I am puzzled. If the latter, the files won't load
> properly if you place links to them in the body.
>

> Tyler- Hide quoted text -

VK

unread,

Mar 26, 2008, 11:13:20 AM3/26/08

to

http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/ddaf4c98dc548f01?hl=en#

Sorry for a delay in answering, I had to be out of town for some time.
I hope you have managed to solve your problem by now. If not yet then:

OK, the second option with iframe w/o src will simply not work: noop,
even if the most beautiful presentation in the world would be in
danger. So let's concentrate on what may work somehow.

> Now a related question, other than setting iframe's designMode to
> "On", is there another way that would allow similar function, that is,
> WYSIWYG editing?

Firefox 3 will finally adopt contenteditable attribute but it doesn't
help too much right now. I am still not clear what does exactly happen
with your iframes after page load but if you need to set them ASAP to
contenteditable then try this trick:

src="blank.html" contenteditable="true"
onload="document.frames['out001'].document.designMode='on';"

style="width:300px; height:150px"></iframe>

Please note that because of race conditions we don't use any "this"
reference in the event handler, otherwise iframe gets loaded before
the mother page does and you'll get run-time error; so we are going
indirectly over document.frames collection which gets created and
updated dynamically even before the mother page fully loaded. It is
not a documented behavior - actually it is a risky convenience added
against the documented requirements. However widely it is exposed
across UAs: you still better check your solution after each major
release of Firefox and IE.

If at the moment of the initial page load you already know what
initial URL for iframe do you need then sure use it:

src="http://www.example.com/cgi-bin/my.cgi?etc"
contenteditable="true"
onload="document.frames['out001'].document.designMode='on';"

style="width:300px; height:150px"></iframe>

If at the moment of the initial page load you don't know what initial
URL for iframe do you need but some script loaded above this point and
not deferred may know it: then use document.write. Say if you have
somewhere among external scripts getUrlForIframe(name) function then
it could be:

and so goes then for all involved frames, respectively changing
frameName for each block. Because it is a streight input stream before
page load, don't you even think :-) to use "this" or "getElementById"
for getUrlForIframe calls: only hardcoded string literals.

Anonymous function wrapper is only to keep frameName and other
possible vars as local so do not pollute the global scope, if you
don't care then you may drop it for simplicity.

Don Li

unread,

Mar 26, 2008, 12:41:58 PM3/26/08

to

On Mar 26, 11:13 am, VK <schools_r...@yahoo.com> wrote:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...

> don't care then you may drop it for simplicity.- Hide quoted text -

>
> - Show quoted text -

Thank you so very much. Very quick question, on your

> <iframe name="out" id="out"
> src="blank.html" contenteditable="true"
> onload="document.frames['out001'].document.designMode='on';"
> style="width:300px; height:150px"></iframe>

Is the "onload" attribute supported by IE6/7 and FireFox2?
Also, this iframe is named and IDed as "out", how come you reference
it as "out001" in the
"document.frames['out001'].document.designMode='on';"?

VK

unread,

Mar 26, 2008, 1:03:25 PM3/26/08

to

It is definitely supported by IE6/7 and Firefox 2.x : this is where I
am testing on.
AFAIK it is also supported by all browsers ever adopted IE's IFRAME
element.

> Also, this iframe is named and IDed as "out", how come you reference
> it as "out001" in the
> "document.frames['out001'].document.designMode='on';"?

Oops - a typo of course. Either "out" or "out001" but not both.

Don Li

unread,

Mar 26, 2008, 2:32:05 PM3/26/08

to

> > Thank you so very much. Very quick question, on your
>
> > > <iframe name="out" id="out"
> > > src="blank.html" contenteditable="true"
> > > onload="document.frames['out001'].document.designMode='on';"
> > > style="width:300px; height:150px"></iframe>
>
> > Is the "onload" attribute supported by IE6/7 and FireFox2?
>
> It is definitely supported by IE6/7 and Firefox 2.x : this is where I
> am testing on.
> AFAIK it is also supported by all browsers ever adopted IE's IFRAME
> element.
>
> > Also, this iframe is named and IDed as "out", how come you reference
> > it as "out001" in the
> > "document.frames['out001'].document.designMode='on';"?
>

> Oops - a typo of course. Either "out" or "out001" but not both.- Hide quoted text -

>
> - Show quoted text -

Thank you very much, I'll re-read and try your method ... and let you
know result.

Don Li

unread,

Mar 26, 2008, 3:52:02 PM3/26/08

to

> know result.- Hide quoted text -

>
> - Show quoted text -

Ok, I just tried it with IE7 and FF2. First, promising progress, I
use your following technique and expand it a bit (may not be for the
unintiated... :)

onload="document.frames['out'].document.designMode='on';"

style="width:300px; height:150px"></iframe>

I got a js err w/ msg of "stack overflow at line 0" upon loading two
test iframes, but the value of your initial sample of "Hello" did show
up in the iframe according to your design and it is EDITABLE, man, it
made me feel good, thank you a million, so, how can we possibly get
rid of the 'stack overflow...' sucker (sorry for the language)?

Don

VK

unread,

Mar 26, 2008, 4:23:31 PM3/26/08

to

"stack overflow at line 0" debugging over a verbal problem
description, w/o source analyzing? Uhm... OK, but I wash my hands
twice from everything before that :-)

Assuming added blocks caused it:

1) Did you ensure that each iframe has unique name/id pair:
iframe name="out001" id="out001"

onload="document.frames['out001'].document.designMode='on';"

iframe name="out002" id="out002"
onload="document.frames['out002'].document.designMode='on';"
iframe name="out003" id="out003"
onload="document.frames['out003'].document.designMode='on';"
etc. ?

2) Very unlikely to be the reason but let's prevent multiple property
set for designMode.

So the final block out of three iframes to insert for testing into
your div would be:

src="blank.html" contenteditable="true"
onload="

if(document.frames['out001'].document.designMode!='on') {
document.frames['out001'].document.designMode!='on';

}"
style="width:300px; height:150px"></iframe>

src="blank.html" contenteditable="true"
onload="

if(document.frames['out002'].document.designMode!='on') {
document.frames['out002'].document.designMode!='on';

}"
style="width:300px; height:150px"></iframe>

src="blank.html" contenteditable="true"
onload="

if(document.frames['out003'].document.designMode!='on') {
document.frames['out003'].document.designMode!='on';

Don Li

unread,

Mar 26, 2008, 6:14:29 PM3/26/08

to

> style="width:300px; height:150px"></iframe>- Hide quoted text -

>
> - Show quoted text -

Ok, here's what I did (I admit I tried to be clever...)
Within the DIV, I have the following:

html','replace');doc.write('<html><body>Hello!</body></
html>');doc.close();"

contentEditable="true" style="width:300px; height:150px"></
iframe><br/>

then, the following iframe too // not meaningful for this test
purpose.

<form id="nutsFrm2" method="post">
<iframe name="nuts2" id="nuts2"

onload="document.frames['nuts2'].document.designMode='on';"
style="width:300px; height:150px"></iframe><br/>
</form>

-------------
So, it looks like the "onload" attribute has limitation on how many
{statements} it supports. And if I move these {statements} to a
separate function and no matter where I put it, top of the page or
bottom, the page would complain that the iframe object or the like not
found or defined...
Catch 22?

Thank you a ton.

VK

unread,

Mar 27, 2008, 9:07:03 AM3/27/08

to

It doesn't. But anything before "document.load" event is left for
developers' peculiarities and we are currently exploring the most
obscure of them. I normally do not go into that quagmire but... it
just puzzled me somehow. So I could repro your "stack overflow line:0"
and it is exactly what we had that summer 1998 between layer and
iframe. We dealt with that, I just need a bit of retro. A race
condition between load event and document.write to fix ...
I need some time.

Don Li

unread,

Mar 27, 2008, 9:12:12 AM3/27/08

to

>
> > <form id="nutsFrm2" method="post">
> > <iframe name="nuts2" id="nuts2"
> > onload="document.frames['nuts2'].document.designMode='on';"
> > style="width:300px; height:150px"></iframe><br/>
> > </form>
>
> > -------------
> > So, it looks like the "onload" attribute has limitation on how many
> > {statements} it supports.
>
> It doesn't. But anything before "document.load" event is left for
> developers' peculiarities and we are currently exploring the most
> obscure of them. I normally do not go into that quagmire but... it
> just puzzled me somehow. So I could repro your "stack overflow line:0"
> and it is exactly what we had that summer 1998 between layer and
> iframe. We dealt with that, I just need a bit of retro. A race
> condition between load event and document.write to fix ...

> I need some time.- Hide quoted text -

>
> - Show quoted text -

Thank you very much for the update...

VK

unread,

Mar 29, 2008, 2:36:16 PM3/29/08

to

On Mar 27, 4:12 pm, Don Li <tatata9...@gmail.com> wrote:
> > > <form id="nutsFrm2" method="post">

> > > <iframename="nuts2" id="nuts2"

1. Initial SRC attribute value for IFRAME
The current URL for SRC defines current cross-domain security policy
for the given pages. Because of that it is not allowed to skip this
attribute even if IFRAME will be used only for dynamically generated
content. A failure to do so will lead to IFRAME run-time scripting
access block. It was true at least for NN4.x/IE4.x/IE5.x
AFAICT at least IE 6.x and Firefox 2.x do allow to skip SRC attribute:
in such case it is being automatically set to the virtual about:blank
page. Anyone is free to use this added convenience but I humbly stay
on the old path. First of all I don't like to torture an engine
without an explicit necessity - even if it is allowed by engine
makers. Secondly a number of spyware and hijacking exploits are using
about: internal URI scheme and the common habit to set about:blank as
the browser's home and/or startup page; therefore many anti-spyware
and anti-hijacking tools are implementing special treatment for
windows and (i)frames with about:blank address up to blocking such
content completely or by blocking scripted access to them. In summary
anyone is free to relay on SRC being set automatically and working
properly: but this option is not considered and not advised by myself.

This way for iframes used as containers for dynamic content - and not
to display physical documents - still initial SRC attribute is always
being set and pointing to a physical document located in the same
domain and subdomain as the mother page to compile with the cross-
domain security requirements.

Such document should be some minimalistic blank HTML document. The
exact suggested content could be:

See: http://www.russiancourses.org/tmp/blank.html

It is based two practical considerations:

1) A document with no content at all in its body section confuses
Firefox if switched to designMode: the initial cursor position will be
set to the upper-right corner as if dir would be right-to-left, but it
gets corrected with the first typed symbol. Obviously it looks very
confusing for end-users. Therefore we are using a paragraph with non-
breaking space in it to fix this behavior.
2) By default IFRAME in Firefox is transparent and in IE is opaque.
That means that the content behind IFRAME will be visible in Firefox.
It may be what you want but most of the time it is not. This is why we
are explicitly setting bgcolor for body.
A note for purists if they are wondering why do not use CSS background-
color instead and stay Strict? First of all it is textually longer and
we want to be as short as possible; and the last but not the least:
hey, we are prepearing to work with IFRAMEs so what Strict are you
talking about? IFRAMEs are not a part of Strict DTD.

2. IFRAME as an editable container
In all samples blank.html assumed to have the exact content as
suggested in the section 1.
All methods are tested on Windows XP SP2 with
Internet Explorer 6.0
Internet Explorer 7.0
Mozilla Firefox 2.0.0.13
Opera 9.26
Safari 3.0.4

A note for purists: DTDs from W3C are missing ONLOAD attribute for
IFRAME in all HTML DTDs. It is a simple typo to disregard: any browser
ever implemented IFRAME also supports documented on MSDN onload event
handler. At the same time W3C Validator will obviously complain.
Either disregard it or use document.write in SCRIPT block to insert
your iframes. Here I am using the first decision.

Option 1 : We just need an empty IFRAME with editing mode being turned
on by default.

Add as reasonably many IFRAMEs as you need: just don't forget to
change "name" and var b\name in each block.

See: http://www.russiancourses.org/tmp/Option1.html

Option 2 : We need to load a document into IFRAME with editing mode
being turned on by default.
Same as Option 1, just use the right src value. Same domain security
rule applies of course, so you can do it only with documents from the
same domain and the same subdomain.

See: http://www.russiancourses.org/tmp/Option2.html

Option 3. We need to load a document into IFRAME with editing mode
being turned on by default. SRC attribute cannot be hardcoded and it
will set on page load. In the sample it is assumed that some of
preliminary loaded scripts has function getUrlForIframe that takes
string argument with the name of iframe and returns src value for that
iframe.

Unfortunately I couldn't find a solution for this option. The sample
code seemingly works for a single iframe, but after that no other
script block is being executed. The function is being executed without
runtime errors as window.alert shows, but any other script is simply
disregarded. The most weird behavior - or maybe I am missing something
obvious. Any feedback is highly appreciated.

See: http://www.russiancourses.org/tmp/Option3.html

Option 4. We need an IFRAME with editing mode being turned on by
default and pre-filled wth some content generated by script.
In the sample it is assumed that some of preliminary loaded scripts
has function getContentForIframe that takes string argument with the
name of iframe and returns HTML code to write into iframe. The only
cross-browser reliable solution I know is to split the task between
IFRAME and SCRIPT blocks. Anything else leads to unhandled race
condition and to "too many recursions" runtime error.

doc.open('text/html','replace');

doc.write(getContentForIframe(name));
doc.close();

if ('designMode' in doc) {

doc.designMode = 'on';
}
}
</script>

See: http://www.russiancourses.org/tmp/Option4.html

VK

unread,

Mar 30, 2008, 5:36:07 AM3/30/08

to

On Mar 29, 10:36 pm, VK <schools_r...@yahoo.com> wrote:
> Option 3. We need to load a document into IFRAME with editing mode
> being turned on by default. SRC attribute cannot be hardcoded and it
> will set on page load. In the sample it is assumed that some of
> preliminary loaded scripts has function getUrlForIframe that takes
> string argument with the name of iframe and returns src value for that
> iframe.
>
> Unfortunately I couldn't find a solution for this option. The sample
> code seemingly works for a single iframe, but after that no other
> script block is being executed. The function is being executed without
> runtime errors as window.alert shows, but any other script is simply
> disregarded. The most weird behavior - or maybe I am missing something
> obvious. Any feedback is highly appreciated.

Lucky I have found the error right at the moment when I was starting
to loose the rest of my mind. How stupid I am: who will close IFRAME?!
I have forgotten to document.write the closing </iframe> tag so the
first IFRAME expanded to the rest of the page. Shame on me... Here the
corrected working version:

http://www.russiancourses.org/tmp/Option3_03_corrected.html

Don Li

unread,

Mar 30, 2008, 12:05:38 PM3/30/08

to

First, let me say I'm deeply indebted to you. All the four options
that you so elegantly elaborated work, however, I'd prefer not to
generate doc01.html,doc02.html... docN.html beforehand . Here I'm
wondering if we can replace the content of the seed html file,
{blank.html} here in this case, on the fly, so, the supporting
javascript function would look like the following,
// my syntax isn't correct, but I don't know how...

function getContentForIframe(n) {
if (n=='doc01') {
replace('blank.html','<html><head><title></title></head><body
bgcolor=##FFFFFF><p>content 1</p></body></html>');
return 'blank.html';
}
if (n=='doc02') {
replace('blank.html','<html><head><title></title></head><body
bgcolor=##FFFFFF><p>content 2</p></body></html>');
return 'blank.html';
}

Is it feasible?

Also, option 4 isn't practical for my case because each script right
after each iframe have problem being executed under this application
server package.

Once again, I'd truly grateful.

> <html><head><title></title></head><body bgcolor="#FFFFFF"><p> </

> See:http://www.russiancourses.org/tmp/Option4.html- Hide quoted text -

VK

unread,

Mar 30, 2008, 1:06:21 PM3/30/08

to

On Mar 30, 8:05 pm, Don Li <tatata9...@gmail.com> wrote:
> First, let me say I'm deeply indebted to you. All the four options
> that you so elegantly elaborated work, however, I'd prefer not to
> generate doc01.html,doc02.html... docN.html beforehand . Here I'm
> wondering if we can replace the content of the seed html file,
> {blank.html} here in this case, on the fly

Which is, by all means, the Option 4:

"Option 4. We need an IFRAME with editing mode being turned on by
default and pre-filled wth some content generated by script."

The "generated content" can be anything, from "Hello world!" to some
complex HTML page: whatever your getContentForIframe will return.

> Also, option 4 isn't practical for my case because each script right
> after each iframe have problem being executed under this application
> server package.

The option 4 doesn't care what else scripts are placed into your page
as long as iframe/script blocks are placed properly where you need
them. Therefore I need more details about their problem of being
executed. Possibly I still do not understand properly the overall
structure of your document.

Don Li

unread,

Mar 30, 2008, 1:30:02 PM3/30/08

to

Sorry, because the weirdness of the app server package that uses some
open source software (not that they are not good but they naturally
requires load sequence etc...).

So, as a workaround, I now have two levels of templates:
top level: include javascripts (they would be loaded)
detail level: better not to load javascript files here (for they have
loading problems), but
at this level, all the iframes reside.

So, if we can change the seed 'blank.html' file content on the fly at
the the top level, it would work as designed.
my following syntax isn't correct... thanks.

if (n=='doc01') {
var str = new String();
str.replace('blank.html','<html><head><title></title></head><body
bgcolor=##FFFFFF><p>Hello 1</p></body></html>');
return 'blank.html';

VK

unread,

Mar 30, 2008, 2:03:55 PM3/30/08

to

Yes, but is it one HTML page as you once posted - however complex it
would be - or is a Ruby-on-Rails like "Matrioshka style" with a script
generating a script that generates a script that ... N ... generates
the content? I am not criticizing anything, I'm only asking for
clarity.

> So, if we can change the seed 'blank.html' file content on the fly

You can't do it. The seed is the seed. As soon as you do the first
document.write into it after iframe load event, it has nothing to do
with blank.html anymore. It is just iframe container filled with
dynamically generated content. If you could move this part of the
logic to the server then you could use Option 3 instead: so for each
iframe an appropriate CGI request URL would be formed and server would
feed the necessary content.
For the option 4 (client-side content feeding over document.write) I
have posted the only working solution I know about - that doesn't mean
that there are not any others, I am just not aware of them.

The Option 5 could be stop trying to accomplish everything right
during the page load. Just wait for main document LOAD event and do
what you need using DOM methods. For your users you can put some nice
"Loading..." animation to keep them happy :-)

Don Li

unread,

Mar 31, 2008, 6:15:57 PM3/31/08

to

> "Loading..." animation to keep them happy :-)- Hide quoted text -

>
> - Show quoted text -

My apologies for not responding on time. I'm wondering how difficult
it is to encapsulate the function as a tiny program, then using it as
an object ... the much disliked (by me or by me only for its bloated
features and naturally slow loading) fukeditor wysiwyg editor works
just like that. Care to consider to work with me on that, and maybe
"offline"?

Many thanks.