Details

If a page is editted and the Cancel button in the upper left is clicked, a pop-up dialog asks if you want to save it. OK saves and Cancel closes without saving, according to the description in the dialog. I have not seen the OK actually save anything.

Test Case

1. Edit a page.
2. Make a change.
3. Click the editor's Cancel button.
4. Click OK to save.
5. Reload or navigate away and back to the page.
6. Change is not there.

I'm pretty sure this is fixed in 0.15, but if someone could check I'd be grateful

-- CrawfordCurrie - 08 Sep 2005

On my install of 0.16 it still does not save (both after using the 'cancel' button in Kupu, using 'Back' in the browser). Saving does work after just killing the browser. I'm using IE6 on Win2K. Also this was tested after disabling SectionalEditPlugin (see above)

-- JosMaccabiani - 09 Sep 2005

I still get this on Rev: 6827, on both IE 6.0.2900 and Firefox 1.07. On pressing Ok in response to the dialog "You have unsaved changes. Do you want to save before leaving the page? (OK to save, Cancel to discard your changes)')" leads the user to view?unlock=on, not to save

It something to do with this code, from pub/TWiki/WysiwygPlugin/kupustart.js:

    var navigatingAway = function () {
      if (kupu.content_changed && 
          confirm('You have unsaved changes. Do you want to save before leaving the page? (OK to save, Cancel to discard your changes)')) {
        kupu.config.reload_src = 0;
        var form = document.getElementById('twiki-main-form');
        TWikiHandleSubmit();
        form.submit();
      };
    }

    if (kupu.getBrowserName() == 'IE') {
        // IE supports onbeforeunload, so let's use that
        addEventHandler(window, 'beforeunload', navigatingAway);
    } else {
        // some versions of Mozilla support onbeforeunload (starting with 1.7)
        // so let's try to register and if it fails fall back on onunload
        var re = /rv:([0-9\.]+)/
        var match = re.exec(navigator.userAgent)
        if (match[1] && parseFloat(match[1]) > 1.6) {
            addEventHandler(window, 'beforeunload', navigatingAway);
        } else {
            addEventHandler(window, 'unload', navigatingAway);
        };
    };

Unlike in edit where leaving the page is corrected by going forward again, leaving a wysiwyg session is fatal: the content is lost. I'd appreciate if others could verify this.

-- MartinCleaver - 07 Nov 2005

Yes Martin, this is the case also with my Kupu Plugin V.0.16!

-- CedricWeber - 07 Nov 2005

I'm wondering, on cancel/back: would it not be better to have "Ok" write to disk the users changes into the edit history and "Cancel" to not leave the edit session?

Or perhaps back/forward can be made to work like with raw edit?

-- MC

I just tested in FF 1.0.4, and when navigating away from the page the save prompt is handled correctly. When going "back" to the page, then the IFRAME that Kupu uses for the edited content is repopulated from the cache, making it look as if the content hasn't changed. A refresh soon shows the latest content.

WysiwygPlugin does everything possible to stop the browser from cacheing the content of the IFRAME. I can't stop it cacheing the entire edit page, as that would block cacheing the javascript and require a full download of the editor code for every edit page. If anyone is interested to try, here's what I tried so far:

1. expires HTTP header & friends in the IFRAME content
   • makes no difference, still gets cached
2. expires HTML meta tag & friends
   • makes no difference
3. onload handler on the IFRAME
   • There is no way to tell if you are visiting the page for the first time, or coming "back" to it.

Anyway, it works as advertised, and as long as you "refresh" when going "back" to an edit, it works fine, so I feel justified in closing this.

CC