Save edits on page unload

[ianb@…]

Right now if you edit some text, then go to another page (maybe go back, or follow some navigational link), and then come back to the editor your edits will be lost.

I believe fixing this just requires putting the content of the editable area into the textarea on page unload.

[kim@…]

In my opinion this has nothing to do with Xinha, this would have to be resolved by your own CMS. Xinha itself doesnt save any content, it lets you edit it. Same thing would be if you have a registration form and instead of clicking the submit button you click a navigational button, depending on the browser, all your inputs will be lost.

In our CMS I tell our customers that nothing is saved until they accually click the update button, giving them a fine way of getting out of the editing mode if they did something wrong. What if you messed up the HTML and click on the "reload" button or another navigational button to start over, and instead the content is infact saved because we developed a nifty save whatever you do function.

You could however easily acomplish your task with javascript and the unload as youself mention, a simple document.form.name.submit() would probably do.

Im setting this ticked to invalid as I cant see this beeing related to Xinha as a WYSIWYG editor.

[niko]

i think ianb is talking about something else, i think i is referring to a browser function that saves the entered form-data when you leave the page, and when you hit back this data will be filled in again into the fields.

FF has this feature, not sure if IE has it too.

and Xinha DOES allready put the content into the textarea on page unload! (at least there is code in htmlarea.js that should do it) i have never actually test it

[niko]

ok, i did a simple test:

1. open full example in FF
2. change some text
3. enter any url in the adressbar
4. click back

the changed text should be here...

perhaps this is a problem only in full_example because the textareas are generated dynamically.

[kim@…]

a browser function that saves the entered form-data when you leave the page, and when you hit back this data will be filled in again into the fields

You lost me, I know this being nice in formfields, if you need to submit same registration twice and only need to alter a little piece of registration (Like registering +1 domains for examaple). IE does this, Firefox doesnt. But if this is what you are referring to I dont see the relevance at the moment. How could javascript remember the html contents, when your not on that particular page - your somewhere else. Wouldnt you need a hidden frame or something on your website to stuff the html so you could get it back? As I said, you lost me, :)

And why should you enter a URL in the address bar? Then you would be telling the browser that I dont want to be on this page, get me out? The CMS should reload the content when you enter the WYSIWYG editor anyways.

Note : What I have noticed however is that it seems that htmlarea adds a point in the history of the browser. (So does fckeditor) Meaning if you enter a page with the editor and hit the back button once, you will still be on the same page but before htmlarea initiated. I do remember having some issues here that the content of the editor didnt reappear if you hit the back button, or something (but why should you? Back buttons are bad in my opinion, hehe, I never expect a websystem to work, take a bank as an example, if you start wandering around forms with back and forth buttons). I tried to reproducse this problem in Firefox, but my Xinha (as of 12 May) do reload the contents every time, so this cant be it.

As I said in the beginning, you lost me, so I might just be rambling here...

[niko]

this is NOT autocomplete or something i'm talking about this:

1. go to www.google.com
2. enter "foobar" in the textfield (just enter it, don't submit the form)
3. enter in your locationbar www.google.com/x
4. you get a 404 page
5. press back in your browser
6. the "foobar" is still in the textbox!!

...works like this in IE6 and FF

7. press forward again
8. enter www.google.com in the locationbar
9. the "foobar" is gone!
10. press back twice
11. its here again

don't know how the feature is called, but it simplified said it saves the form-data kind of in the history, which is a very useful feature (when posting in forums for example).

...and this has nothing todo with xinha being twice in the history - because you don't click back when you are on the xinha-page.

...and the broken thing is that this doesn't work in combination with xinha - because onunload the xinha-contents needs to be written into the textarea. See line 1372 in htmlarea.js

i hope you understand what i wrote :D

[niko]

...and i just tested this using examples/testbed.html and it IS broken. (IE and FF)

when i switch off JavaScript? it works.

[kim@…]

I havnt checked, but I think this has to do with the following, if i create this :

<input type="text" name="a" value="">

It will work as you mentioned, however if I do this :

<input type="text" name="a" value="something">

Then "something" will reapear instead of whatever you wrote in the field, it only works aslong as the value isnt set I think.

[niko]

Checked this for FF and it does not work like you suggested. FF just ignores the value. (same with a textarea)

I also did some debugging on this, the onunload event is called, and the value of the textarea is set right. i have no idea what could be the problem here.

[anonymous]

This might be (and for me, it is) a big usability issue. If one submits the page to a "Preview and Submit" screen (much like the one right here), and the user decided they want to change something, the back button loses all previous edits. This works fine in the original htmlarea.

Looks like this is controlled by the body.unload event that calls:

textarea.value = editor.outwardHtml(editor.getHTML());

The textarea value is indeed set to the current value (proven by a simple alert(textarea.name + ' = '+textarea.value)) but it somehow doesn't retain the value when you come back to the page.

[gogo]

It may be necessary to set textarea.innerHTML

[niko]

Setting textarea.innerHTML didn't help.

i wrote a little testcase that sets the value of a textarea on onload:

<html>
<head>
  <script language="JavaScript">
    window.onunload = function() {
        alert(document.getElementById('foo').value);
        document.getElementById('foo').value = "fooobar";
        alert(document.getElementById('foo').value);
    }
  </script>
</head>
<body>
<form>
  <textarea id="foo">asdfasdf</textarea>
</form>
</body>
</html>

....which works for me

[gogo]

But isn't that exactly what we do now?

[niko]

yes, we do... i even made the textarea visible in the onunload and it shows the right content.

i can't do anything more on this ticket, somebody should probably do some internal FF-debugging!?

[anonymous]

It's not FF only. I can reproduce it in IE, Netscape 7.1 and 7.2 too. The field definitely sets the value right, if you do a form-post it goes in correctly. The funny thing is that original HTMLArea works fine, and I even tried the same (equivalent) assignment in the onLoad handler with no luck. Something must have changed in the way the variables are being assigned somewhere.

[gogo]

I don't know what's going on here, the value is definatly set on it's way out, but it's different coming back. I'm going to bump this to V2.0 because I don't think it's worth blocking 1.0 with it.

[wikiwhacker]

This problem was cited in ticket #537, which was deleted. This is a show-stopper problem for us to use Xinha for 70 authors. If there's no fix, then Xinha is no longer an option.

[gogo]

wikiwhacker: I don't think #537 is a dup of this, see my comments there.

[mharrisonline]

I know this isn't the way you want this to work, but you could provide a preview button that opens a resizable popup window with scrollbars. That is what I do, and it really shows well what the page will look like. If you don't want the preview to be in a new window, then perhaps it could be in a div or iframe that could temporarily cover the editor. Then, Xinha never needs to go away and the editor contents are undisturbed.

[anonymous]

I don't think this is a blocking feature, it can be solved outside xinha, the browser back button is not a matter of an editor since each browser maintain cronology in a different way.