IE problem with iframe reload

D

DL

Hi,

I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).

The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)

More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)

js within header
----------------

function setFrm() {
var fh = document.getElementById('tb');
fh.style.width = (screen.width * 0.85)+"px";
fh.style.height = (screen.height - 350)+"px";
}


if (navigator.appCodeName == 'Mozilla') {
var Editor1 = document.getElementById('tb').contentWindow.document;
}
else
var Editor1 = document.frames['tb'].document;


html body
---------
<body bgcolor="##ECECFF" onload="setFrm();">

<form...>

<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>

<input type="hidden" id="nt" name="nt"/>

<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">

</form>


Thanks in advance.
 
D

DL

Hi,

I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).

The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)

More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)

js within header
----------------

        function setFrm() {
        var fh = document.getElementById('tb');
                        fh.style.width = (screen.width * 0.85)+"px";
                        fh.style.height = (screen.height - 350)+"px";
        }

        if (navigator.appCodeName == 'Mozilla') {
        var Editor1 = document.getElementById('tb').contentWindow.document;
        }
        else
                var Editor1 = document.frames['tb'].document;

html body
---------
<body bgcolor="##ECECFF" onload="setFrm();">

<form...>

<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>

<input type="hidden" id="nt" name="nt"/>

<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">

</form>

Thanks in advance.
Click to expand...

Additional info.

start or link page
<input type="button" id="t1" onclick="window.open('editme.cfm?
meid=107','editEntry1','width='+(screen.width-50)+',height='+
(screen.height-50)+',resizable=yes,scrollbars=yes');"
style="color:blue" value=" Edit ">&nbsp;<br/>

-> editme.cfm page
Firebug lite console:
"Object required (editme.cfm?meid=107,305)"

Why? Where does the 305 extra id come from? And why did it
complained about object not found here?

Thanks.
 
D

David Mark

DL said:
Hi,

I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).
Click to expand...

Which one then? :) I'll assume both.
The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
Click to expand...

If your only clue to the veracity of your logic is that the application
appears to work in three browsers (in whatever configuration you have
them in), you haven't really got a leg to stand on. In other words, if
you don't *understand* the abstractions in play, how can you feel secure
about IE8, FF4, etc.
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)
Click to expand...

So there is a problem with FF then?
More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)

js within header
----------------

function setFrm() {
var fh = document.getElementById('tb');
fh.style.width = (screen.width * 0.85)+"px";
fh.style.height = (screen.height - 350)+"px";
Click to expand...

Don't use screen.* as you have no idea how those dimensions relate to
the browser window. What is it you are trying to do here?
}


if (navigator.appCodeName == 'Mozilla') {
Click to expand...

Clearly my initial presumption was correct. You are simply rearranging
code until it appears to "work" and using browser sniffing to boot.
Such strategies are doomed to fail.

http://www.jibbering.com/faq/notes/detect-browser/
var Editor1 = document.getElementById('tb').contentWindow.document;
Click to expand...

It is preferable to use contentDocument where available as there is no
standard for contentWindow. You've made a bad assumption based on a bad
inference and concluded it "works" due to empirical evidence gathered
from three browsers
}
else
var Editor1 = document.frames['tb'].document;
Click to expand...

And why did you do this at all? IE supports contentWindow. I can only
assume you copied it from a Website. That's usually the kiss of death
as 99.9% of the JS floating around out there is junk code (as we see here).
html body
Click to expand...

Don't use the deprecated bgcolor attribute. Use a style sheet. And you
forgot to set the foreground color as well. Good job using the onload
attribute though (that's the first thing you did right and I assume it
was accidental).
<form...>
Huh?


<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>
Click to expand...

Where's the sniff? Above you only used that pattern for IE. :) And
why the contenteditable attribute? The designMode property set will do
fine.
<input type="hidden" id="nt" name="nt"/>
Click to expand...

The slash is an error. This is clearly not XHTML.
<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">
Click to expand...

Don't post server side directives in your example code. It makes it
difficult to read. Post the results of the server side script.
</form>


Thanks in advance.
Click to expand...

NP, but you've given me nothing useful to work with. I don't even see
where you've described the problem.

http://www.jibbering.com/faq/notes/posting/#ps1DontWork

And a word of advice. Creating a cross-browser rich text editing
application appears to be well outside your current range. I'd
seriously consider farming this out. I just built something like this
for a client last week. Drop me a line if you have a budget allocated
(it won't be cheap). The alternative is tons of frustration and misery
that will ultimately end in failure. I've seen it happen many times
(and to much more advanced developers than yourself). ;)
 
D

DL

For a short follow-up I'll just do top post, bear with me.
With regard to "contentWindow vs.
It is preferable to use contentDocument", are you saying
contentDocument is supported by IE7/IE8, FF3.x and the new FF4.x and
possibly Chrome as well?

Thanks. FYI, yeah, "accidentially" I've made it working across two
browsers so far and no, not intended to support all browsers and all
versions.
Hi,
Click to expand...
I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).
Click to expand...

Which one then?  :)  I'll assume both.


The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
Click to expand...

If your only clue to the veracity of your logic is that the application
appears to work in three browsers (in whatever configuration you have
them in), you haven't really got a leg to stand on.  In other words, if
you don't *understand* the abstractions in play, how can you feel secure
about IE8, FF4, etc.
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)
Click to expand...

So there is a problem with FF then?


More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)
Click to expand...
js within header
----------------
Click to expand...
   function setFrm() {
   var fh = document.getElementById('tb');
                   fh.style.width = (screen.width* 0.85)+"px";
                   fh.style.height = (screen.height - 350)+"px";
Click to expand...

Don't use screen.* as you have no idea how those dimensions relate to
the browser window.  What is it you are trying to do here?
   }
Click to expand...
   if (navigator.appCodeName == 'Mozilla') {
Click to expand...

Clearly my initial presumption was correct.  You are simply rearranging
code until it appears to "work" and using browser sniffing to boot.
Such strategies are doomed to fail.

http://www.jibbering.com/faq/notes/detect-browser/
   var Editor1 = document.getElementById('tb').contentWindow.document;
Click to expand...

It is preferable to use contentDocument where available as there is no
standard for contentWindow.  You've made a bad assumption based on a bad
inference and concluded it "works" due to empirical evidence gathered
from three browsers
   }
   else
           var Editor1 = document.frames['tb'].document;
Click to expand...

And why did you do this at all?  IE supports contentWindow.  I can only
assume you copied it from a Website.  That's usually the kiss of death
as 99.9% of the JS floating around out there is junk code (as we see here).


html body
Click to expand...

Don't use the deprecated bgcolor attribute.  Use a style sheet.  And you
forgot to set the foreground color as well.  Good job using the onload
attribute though (that's the first thing you did right and I assume it
was accidental).


<form...>
Huh?



<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>
Click to expand...

Where's the sniff?  Above you only used that pattern for IE.  :)  And
why the contenteditable attribute?  The designMode property set will do
fine.


<input type="hidden" id="nt" name="nt"/>
Click to expand...

The slash is an error.  This is clearly not XHTML.


<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">
Click to expand...

Don't post server side directives in your example code.  It makes it
difficult to read.  Post the results of the server side script.


</form>
Click to expand...
Thanks in advance.
Click to expand...

NP, but you've given me nothing useful to work with.  I don't even see
where you've described the problem.

http://www.jibbering.com/faq/notes/posting/#ps1DontWork

And a word of advice.  Creating a cross-browser rich text editing
application appears to be well outside your current range.  I'd
seriously consider farming this out.  I just built something like this
for a client last week.  Drop me a line if you have a budget allocated
(it won't be cheap).  The alternative is tons of frustration and misery
that will ultimately end in failure.  I've seen it happen many times
(and to much more advanced developers than yourself).  ;)
Click to expand...
 
D

David Mark

DL said:
For a short follow-up I'll just do top post, bear with me.
Why?

With regard to "contentWindow vs.
It is preferable to use contentDocument", are you saying
contentDocument is supported by IE7/IE8, FF3.x and the new FF4.x and
possibly Chrome as well?
Click to expand...

AFAIK it is, but that's beside the point. One of the wonderful things
about feature testing is that you let the code do the work and forget
about memorizing and endless empirical data gathering. Anyway, it is a
standard, whereas the other is not. When faced with a choice between a
standard and a non-standard, you generally choose the former.
Thanks. FYI, yeah, "accidentially" I've made it working across two
browsers so far and no, not intended to support all browsers and all
versions.
Click to expand...

I presume you won't be putting it on the Web then. And FYI, using
UA-sniffing does not count as "working". In fact, it is an admission
that you could not make your design work. Those who say otherwise seem
to miss the fact that there's not time to go back and rewrite every
project when the faulty inferences inevitably fall apart. Working
means, barring bizarre circumstances, a Web app should work virtually
forever (particularly if it sticks to standards).
Hi,
I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).
Click to expand...
Which one then? :) I'll assume both.


The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
Click to expand...
If your only clue to the veracity of your logic is that the application
appears to work in three browsers (in whatever configuration you have
them in), you haven't really got a leg to stand on. In other words, if
you don't *understand* the abstractions in play, how can you feel secure
about IE8, FF4, etc.
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)
Click to expand...
So there is a problem with FF then?


More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)
js within header
----------------
function setFrm() {
var fh = document.getElementById('tb');
fh.style.width = (screen.width * 0.85)+"px";
fh.style.height = (screen.height - 350)+"px";
Click to expand...
Don't use screen.* as you have no idea how those dimensions relate to
the browser window. What is it you are trying to do here?
}
if (navigator.appCodeName == 'Mozilla') {
Click to expand...
Clearly my initial presumption was correct. You are simply rearranging
code until it appears to "work" and using browser sniffing to boot.
Such strategies are doomed to fail.

http://www.jibbering.com/faq/notes/detect-browser/
var Editor1 = document.getElementById('tb').contentWindow.document;
Click to expand...
It is preferable to use contentDocument where available as there is no
standard for contentWindow. You've made a bad assumption based on a bad
inference and concluded it "works" due to empirical evidence gathered
from three browsers
}
else
var Editor1 = document.frames['tb'].document;
Click to expand...
And why did you do this at all? IE supports contentWindow. I can only
assume you copied it from a Website. That's usually the kiss of death
as 99.9% of the JS floating around out there is junk code (as we see here).


html body
Click to expand...
Don't use the deprecated bgcolor attribute. Use a style sheet. And you
forgot to set the foreground color as well. Good job using the onload
attribute though (that's the first thing you did right and I assume it
was accidental).


<form...> Huh?



<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>
Click to expand...
Where's the sniff? Above you only used that pattern for IE. :) And
why the contenteditable attribute? The designMode property set will do
fine.


<input type="hidden" id="nt" name="nt"/>
Click to expand...
The slash is an error. This is clearly not XHTML.


<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">
Click to expand...
Don't post server side directives in your example code. It makes it
difficult to read. Post the results of the server side script.


</form>
Thanks in advance.
Click to expand...
NP, but you've given me nothing useful to work with. I don't even see
where you've described the problem.

http://www.jibbering.com/faq/notes/posting/#ps1DontWork

And a word of advice. Creating a cross-browser rich text editing
application appears to be well outside your current range. I'd
seriously consider farming this out. I just built something like this
for a client last week. Drop me a line if you have a budget allocated
(it won't be cheap). The alternative is tons of frustration and misery
that will ultimately end in failure. I've seen it happen many times
(and to much more advanced developers than yourself). ;)
Click to expand...
Click to expand...
 
D

DL

DL said:
For a short follow-up I'll just do top post, bear with me.
Why?

With regard to "contentWindow vs.
It is preferable to use contentDocument", are you saying
contentDocument is supported by IE7/IE8, FF3.x and the new FF4.x and
possibly Chrome as well?
Click to expand...

AFAIK it is, but that's beside the point.  One of the wonderful things
about feature testing is that you let the code do the work and forget
about memorizing and endless empirical data gathering.  Anyway, it is a
standard, whereas the other is not.  When faced with a choice between a
standard and a non-standard, you generally choose the former.


Thanks.  FYI, yeah, "accidentially" I've made it working across two
browsers so far and no, not intended to support all browsers and all
versions.
Click to expand...

I presume you won't be putting it on the Web then.  And FYI, using
UA-sniffing does not count as "working".  In fact, it is an admission
that you could not make your design work.  Those who say otherwise seem
to miss the fact that there's not time to go back and rewrite every
project when the faulty inferences inevitably fall apart.  Working
means, barring bizarre circumstances, a Web app should work virtually
forever (particularly if it sticks to standards).


DL wrote:
Hi,
I'm having a problem with iframe reload upon data saving with ie7
(tested on XP) or ie8 (tested on windows 7).
Which one then?  :)  I'll assume both.
The flow of the page is:
a) automatically saving/updating data inside the iframe while a user
is typing... (no problem with Firefox 3.5.x or IE7/8)
If your only clue to the veracity of your logic is that the application
appears to work in three browsers (in whatever configuration you have
them in), you haven't really got a leg to stand on.  In other words,if
you don't *understand* the abstractions in play, how can you feel secure
about IE8, FF4, etc.
b) upon clicking on the Save button, manually save/update and refresh
the screen including reloading the iframe (no problem with Firefox but
the iframe fails to resize per js instruction)
So there is a problem with FF then?
More detail of the problem (I've omitted the automatic data saving
part for not cluttering the screen but will post more code if
necessary)
js within header
----------------
   function setFrm() {
   var fh = document.getElementById('tb');
                   fh.style.width = (screen.width * 0.85)+"px";
                   fh.style.height = (screen.height - 350)+"px";
Don't use screen.* as you have no idea how those dimensions relate to
the browser window.  What is it you are trying to do here?
   }
   if (navigator.appCodeName == 'Mozilla') {
Clearly my initial presumption was correct.  You are simply rearranging
code until it appears to "work" and using browser sniffing to boot.
Such strategies are doomed to fail.
http://www.jibbering.com/faq/notes/detect-browser/
   var Editor1 = document.getElementById('tb').contentWindow.document;
It is preferable to use contentDocument where available as there is no
standard for contentWindow.  You've made a bad assumption based on abad
inference and concluded it "works" due to empirical evidence gathered
from three browsers
   }
   else
           var Editor1 = document.frames['tb'].document;
And why did you do this at all?  IE supports contentWindow.  I canonly
assume you copied it from a Website.  That's usually the kiss of death
as 99.9% of the JS floating around out there is junk code (as we see here).
html body
---------
<body bgcolor="##ECECFF" onload="setFrm();">
Don't use the deprecated bgcolor attribute.  Use a style sheet.  And you
forgot to set the foreground color as well.  Good job using the onload
attribute though (that's the first thing you did right and I assume it
was accidental).
<form...>
Huh?
<iframe id="tb" name="tb" src="getData.html"
onload="document.frames['tb'].document.designMode='on';"
contenteditable="true"></iframe>
Where's the sniff?  Above you only used that pattern for IE.  :)  And
why the contenteditable attribute?  The designMode property set willdo
fine.
<input type="hidden" id="nt" name="nt"/>
The slash is an error.  This is clearly not XHTML.
<input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
document.frames['tb'].document;var nt =
document.getElementById('nt');nt.value =
Editor1.body.innerHTML;"<cfelse>"var Editor1 =
document.getElementById('textbox').contentWindow.document;var nt =
document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
cfif> style="background-color:##BDD3FF;color:black">
Don't post server side directives in your example code.  It makes it
difficult to read.  Post the results of the server side script.
</form>
Thanks in advance.
NP, but you've given me nothing useful to work with.  I don't even see
where you've described the problem.
http://www.jibbering.com/faq/notes/posting/#ps1DontWork
And a word of advice.  Creating a cross-browser rich text editing
application appears to be well outside your current range.  I'd
seriously consider farming this out.  I just built something like this
for a client last week.  Drop me a line if you have a budget allocated
(it won't be cheap).  The alternative is tons of frustration and misery
that will ultimately end in failure.  I've seen it happen many times
(and to much more advanced developers than yourself).  ;)
Click to expand...
Click to expand...
Click to expand...

The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).

Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;

And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var. How come?
Or possibly something else?

Thanks.
 
D

David Mark

DL wrote:

[...]
The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).
Click to expand...

And you never intend to change them?
Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;

And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var. How come?
Click to expand...

Because you are just guessing. Google for "contentDocument". It would
have saved some time if you'd done that before posting again.
 
D

DL

DL wrote:

[...]


The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).
Click to expand...

And you never intend to change them?


Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;
Click to expand...
And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var.  How come?
Click to expand...

Because you are just guessing.  Google for "contentDocument".  It would
have saved some time if you'd done that before posting again.
Click to expand...

Previous experience of googling with this sort of problem wasn't
always productive... Anyway, the following code, which seems to cover
"all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
baffled:

var f = document.getElementById('textbox');
var Editor1 = (f.contentDocument.document || f.contentWindow.document
|| f.contentDocument);
// the Editor1 var is on one line

Thanks.
 
D

David Mark

DL said:
DL wrote:

[...]


The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).
Click to expand...
And you never intend to change them?


Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;
And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var. How come?
Click to expand...
Because you are just guessing. Google for "contentDocument". It would
have saved some time if you'd done that before posting again.
Click to expand...

Previous experience of googling with this sort of problem wasn't
always productive...
Click to expand...

I asked you to Google a property name (contentDocument) so you would see
the obvious mistake you made.
Anyway, the following code, which seems to cover
"all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
baffled:

var f = document.getElementById('textbox');
Click to expand...

What is that? An IFRAME or a text input?
var Editor1 = (f.contentDocument.document || f.contentWindow.document
|| f.contentDocument);
// the Editor1 var is on one line
Click to expand...

What makes you think contentDocument has a "document" property? That's
why I asked you to look up the documentation (or any example that uses
that property successfully).

First hit:-

http://msdn.microsoft.com/en-us/library/cc196985(VS.85).aspx

Also, you should really learn to use a debugger (e.g. Firebug). That
would have clued you in to at least one mistake. Are you starting to
realize you are in over your head?
 
D

DL

DL said:
DL wrote:
[...]
The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).
And you never intend to change them?
Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;
And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var.  How come?
Because you are just guessing.  Google for "contentDocument".  It would
have saved some time if you'd done that before posting again.
Click to expand...
Click to expand...
Previous experience of googling with this sort of problem wasn't
always productive...
Click to expand...

I asked you to Google a property name (contentDocument) so you would see
the obvious mistake you made.
Anyway, the following code, which seems to cover
"all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
baffled:
Click to expand...
var f = document.getElementById('textbox');
Click to expand...

What is that?  An IFRAME or a text input?
var Editor1 = (f.contentDocument.document || f.contentWindow.document
|| f.contentDocument);
// the Editor1 var is on one line
Click to expand...

What makes you think contentDocument has a "document" property?  That's
why I asked you to look up the documentation (or any example that uses
that property successfully).

First hit:-

http://msdn.microsoft.com/en-us/library/cc196985(VS.85).aspx

Also, you should really learn to use a debugger (e.g. Firebug).  That
would have clued you in to at least one mistake.  Are you starting to
realize you are in over your head?
Click to expand...

Please see below.
What is that? An IFRAME or a text input?
Click to expand...
Sorry, too lazy.. should have named it something like "frm" something.

Yes, I used the firebug for FF3.5 on the dev box. Just install it to
my Vista box, and it found that the FORM element of "subject" not
found... and bump out.

More info:
The page has a form named "edit" with id also "edit" with fields
include "subject".

And on the js side, as posted before, has
....
d.setForm('edit'); // set form name
d.setHTTPMethod('POST'); // specify form submission method
d.doUpdate(); // call a function

Odd stuff:
How come IE7 or IE8 can submit the form correctly with all fields
intact including "Subject" while Firefox (3.5 or 3.5.9) failed to
include field of "Subject"? a reserved word? if so it would be
weird...

And the key part of the current code look like this:
var f = document.getElementById('frm');
var Editor1 = f.contentDocument;
if (Editor1 && document.getElementById('subject'))
{
document.getElementById('notes').value = Editor1.body.innerHTML;
if (document.getElementById('subject').value !== '' ||
document.getElementById('notes').value !== '') {
d.setForm('edit');
d.setHTTPMethod('POST');
d.doUpdate();
}
}

Thanks.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Newer versions of Firefox are trouble-makers 11
Code works with IE7, FF3.5 but not IE8 and Why? 2
URL problem inside an IFRAME 0
IE + Iframe popup problem 1
Problem with contentWindow - returns different object in FF and IE 7
How to pass the hidden field's value within the context of iframe? 1
Problem with reload 15
Help with my responsive home page 2

Members online

Total: 22 (members: 1, guests: 21)
Robots: 495

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top