search

sleemanj / xinha

WYSIWYG HTML Editor Component (turns <textarea> into HTML editors)
http://trac.xinha.org/
Other
13 stars 2 forks source link

Save changes on page unload (Trac #929) #929

Closed sleemanj closed 4 years ago

sleemanj commented 17 years ago

Frmo the forum http://xinha.gogo.co.nz/punbb/viewtopic.php?id=942

#!html

<div id="p4419" class="blockpost rowodd firstpost">
  <h2><span><span class="conr">#1&nbsp;</span><a href="viewtopic.php?pid=4419#p4419">Yesterday 23:11:03</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2489">tdxdave</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3>Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>A user is editing content with Xinha editor. Navigates to another page. Clicks back to go back to Xinha editor page. The content the user entered is gone. This is not the expected behavior. Does this always happen with xinha or might it be a configuration issue?
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div id="p4420" class="blockpost roweven">
  <h2><span><span class="conr">#2&nbsp;</span><a href="viewtopic.php?pid=4420#p4420">Today 00:44:24</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=470">koto</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>This is an expected behaviour. Xinha initalizes with contents of TEXTAREA element associated with it. Is the user navigates to the other page without submitting the form, there is no way for the server serving HTML page to determine "previous" state of the textarea.
            <br />
            <br />Some browsers do populate textareas and/or input field based on their cached contents, but AFAIK Xinha can't access these values.
            <br />
            <br />If you want to be able to save the content while editing the document, please look at the SaveSubmit plugin.
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div id="p4421" class="blockpost rowodd">
  <h2><span><span class="conr">#3&nbsp;</span><a href="viewtopic.php?pid=4421#p4421">Today 00:48:15</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2489">tdxdave</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>In this case the server is never contacted, the page is loaded from the browser cache.
            <br />I asked an associate about other wysiwyg editors, and he said TinyMCE has the expected behavior (ie: edits are not lost). I will research some more. Perhaps there is some way to populate a placeholder textarea and reload xinha with it when the browser goes back to the cached page.
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div id="p4422" class="blockpost roweven">
  <h2><span><span class="conr">#4&nbsp;</span><a href="viewtopic.php?pid=4422#p4422">Today 02:51:15</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2489">tdxdave</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>Ie: <a href="http://tinymce.moxiecode.com/example_full.php?example=true">http://tinymce.moxiecode.com/example_fu … ample=true</a> This works as expected. If you enter content in tinymce then browse to a new page then click "back" the content is still there.
            <br />
            <br />This: <a href="http://xinha.gogo.co.nz/xinha-nightly/examples/ext_example.html">http://xinha.gogo.co.nz/xinha-nightly/e … ample.html</a> does not.
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div id="p4423" class="blockpost rowodd">
  <h2><span><span class="conr">#5&nbsp;</span><a href="viewtopic.php?pid=4423#p4423">Today 04:00:23</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2489">tdxdave</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>I found this code
            <br />
            <br />&nbsp; // add a handler for the "back/forward" case -- on body.unload we save
            <br />&nbsp; // the HTML content into the original textarea.
            <br />&nbsp; Xinha.prependDom0Event(
            <br />&nbsp; &nbsp; window,
            <br />&nbsp; &nbsp; 'unload',
            <br />&nbsp; &nbsp; function()
            <br />&nbsp; &nbsp; {
            <br />&nbsp; &nbsp; &nbsp; textarea.value = editor.outwardHtml(editor.getHTML());
            <br />&nbsp; &nbsp; &nbsp; &nbsp; return true;
            <br />&nbsp; &nbsp; }
            <br />&nbsp; );
            <br />
            <br />Which appears to save the content in the textarea before you leave the page. So it looks like the problem is when I come _back_ to the page its somehow getting the wrong value.
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div id="p4425" class="blockpost roweven">
  <h2><span><span class="conr">#6&nbsp;</span><a href="viewtopic.php?pid=4425#p4425">Today 11:40:47</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2216">jedi58</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>yeah I think by the time an onunload function has been called, any changes are going to be lost as they're not remembered by the browser past that point
          </p>
        </div>
        <div class="postsignature">
          <hr />David G. Paul
          <br /><a href="http://www.newearthonline.co.uk">http://www.newearthonline.co.uk</a>
        </div>
      </div>
      <div class="clearer">
      </div>
      <br />
    </div>
  </div>
</div>
<div id="p4427" class="blockpost rowodd">
  <h2><span><span class="conr">#7&nbsp;</span><a href="viewtopic.php?pid=4427#p4427">Today 16:14:14</a></span>
  </h2>
  <div class="box">
    <div class="inbox">
      <div class="postleft"> <dl> <dt><strong><a href="profile.php?id=2489">tdxdave</a></strong></dt></dl>
      </div>
      <div class="postright">
        <h3> Re: Correct behavior when user navigates back to a page with Xin
        </h3>
        <div class="postmsg">
          <p>Interesting if the browser loses the changes. I poked around the source of TinyMCE and it appears to do the same thing. One thing I did not see if moving the textarea inside the iframe. That is Xinha changes the DOM and moves the textarea for the form inside the iframe, at least that is what appears to happen.
          </p>
        </div>
      </div>
      <div class="clearer">
      </div>
    </div>
  </div>
</div>
<div class="blockform">
  <div class="box">
    <form method="post" action="post.php?tid=942" onsubmit="this.submit.disabled=true;if(process_form(this)){return true;}else{this.submit.disabled=false;return false;}">
    </form>
  </div>
</div>

Reported by ray, migrated from http://trac.xinha.org/ticket/929

sleemanj commented 17 years ago

ray commented:

Yes, it seems the browser looses the association with the original textarea. I've tried it without moving the textarea (btw. it's not moved inside the iframe, only in the table framework), but unfortunately without any success :(

sleemanj commented 17 years ago

ray commented:

rev 768: fixed for Mozilla. As I noticed tinyMCE doesn't have this in IE either...

The point here was the additional form elements generated by Xinha (toolbar selects, inline dialogs)

sleemanj commented 17 years ago

So, fixed.