Prev: keyboard commands?
Next: FAQ Topic - What is a function statement? (2010-05-24)
From: DL on 23 May 2010 13:42
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.

From: DL on 23 May 2010 13:57
On May 23, 1:42 pm, DL <tatata9...(a)gmail.com> wrote:
> 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.

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.
From: David Mark on 23 May 2010 14:28
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 a bad
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 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
> ---------
> <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 will do
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). ;)
From: DL on 23 May 2010 20:00
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.

>On May 23, 2:28 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> 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 a bad
> 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 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
> > ---------
> > <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 will do
> 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).  ;)

From: David Mark on 23 May 2010 20:19
DL wrote:
> 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?

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.

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).

>
>> On May 23, 2:28 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>> 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 a bad
>> 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 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
>>> ---------
>>> <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 will do
>> 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). ;)
>
 |  Next  |  Last
Pages: 1 2
Prev: keyboard commands?
Next: FAQ Topic - What is a function statement? (2010-05-24)