IE problem with iframe reload

Discussion in 'Javascript' started by DL, May 23, 2010.

  1. DL

    DL Guest

    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.
     
    DL, May 23, 2010
    #1
    1. Advertising

  2. DL

    DL Guest

    On May 23, 1:42 pm, 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).
    >
    > 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.
     
    DL, May 23, 2010
    #2
    1. Advertising

  3. DL

    David Mark Guest

    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). ;)
     
    David Mark, May 23, 2010
    #3
  4. DL

    DL Guest

    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 <> 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).  ;)
     
    DL, May 24, 2010
    #4
  5. DL

    David Mark Guest

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

    >
     
    David Mark, May 24, 2010
    #5
  6. DL

    DL Guest

    On May 23, 8:19 pm, David Mark <> wrote:
    > 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 <> 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 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).  ;)

    >
    >


    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.
     
    DL, May 24, 2010
    #6
  7. DL

    David Mark Guest

    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.
     
    David Mark, May 24, 2010
    #7
  8. DL

    DL Guest

    On May 24, 10:20 am, David Mark <> wrote:
    > 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.


    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.
     
    DL, May 24, 2010
    #8
  9. DL

    David Mark Guest

    DL wrote:
    > On May 24, 10:20 am, David Mark <> wrote:
    >> 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.

    >
    > Previous experience of googling with this sort of problem wasn't
    > always productive...


    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');


    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
    >


    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?
     
    David Mark, May 24, 2010
    #9
  10. DL

    DL Guest

    On May 24, 11:19 am, David Mark <> wrote:
    > DL wrote:
    > > On May 24, 10:20 am, David Mark <> wrote:
    > >> 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.

    >
    > > Previous experience of googling with this sort of problem wasn't
    > > always productive...

    >
    > 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');

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

    >
    > 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?


    Please see below.

    > > var f = document.getElementById('textbox');

    >
    > What is that? An IFRAME or a text input?

    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.
     
    DL, May 24, 2010
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joshua Beall
    Replies:
    26
    Views:
    221,740
    AndreiKaa
    Jun 29, 2007
  2. gen_tricomi
    Replies:
    2
    Views:
    767
    gen_tricomi
    May 23, 2006
  3. bb
    Replies:
    1
    Views:
    168
    Thomas 'PointedEars' Lahn
    Nov 6, 2003
  4. Daedalous
    Replies:
    3
    Views:
    754
    Daedalous
    Jan 16, 2004
  5. Stefan Mueller
    Replies:
    4
    Views:
    309
    Stefan Mueller
    Nov 5, 2005
Loading...

Share This Page