Browser doesn't re-fill form on return, if plugin is enabled

[Steve Strobel]

When editing a wiki page in Trac without this plugin enabled, if I accidentally press the browser's back button or follow a link to a different page (the roadmap for example) without first saving my changes, I can navigate back to the wiki page and my changes will still be there. When this plugin is installed, I can navigate back to the wiki page, but any changes I made disappear, which can result in lost work. Tested using Firefox 3.0.3.

[echarpentier@…]

There is another plugin which mostly handles this situation: DataSaverPlugin

But when leaving the form and coming back, the textarea is saved and can be restored back. For the current wysiwyg plugin, you would need to add the following line (line 204) so that it is saved "if" you leave the page

top.onbeforeunload = listener;

When restoring back, only the textarea is managed! Thus you would need to come back to the form, switch to textarea, restore form and only then switch back to wysiwyg.

[Steve Strobel]

Thanks for the pointer to DataSaverPlugin. Using a cookie like that is clever, and should work in most cases.

Ideally, such a plugin wouldn't be needed. When TracWysiwygPlugin is disabled, I can reload the page, navigate to other pages and return, or even shut down Windows while Firefox is open and have the form refilled when I restart Windows and Firefox (which has some plugins installed - I don't know if they have any effect or not). None of those cases work when TracWysiwygPlugin is enabled, even if editing using the textarea mode rather than WYSIWYG. It might not even be possible, though, to keep those things working and support WYSIWYG editing; I don't understand the implementation well enough to know what the constraints are.

I will give DataSaverPlugin a try. If it keeps me from losing big edits, I won't mind having to switch to textarea mode to do the restore at all :)

[Steve Strobel]

I am guessing that the file you suggested modifying to add line 204 is /root/.python-eggs/TracWysiwyg-0.2_r4214-py2.5.egg-tmp/tracwysiwyg/htdocs/wysiwyg.js, and that in context it would be:

    addEvent(this.textarea.form, "submit", listener);
    top.onbeforeunload = listener;
};

I added that and restarted tracd, but after reloading a wiki page or navigating to another page then returning, the "Restore Form" link is always dim and when clicked just displays the message, "No form data is available for restoration." What am I missing?

[anonymous]

You are right yes, it's the wysiwyg.js file :)

Could you try, just to see if the javascript hook are there

• click on textarea edition
• fill the form
• click on wysiwyg edition (just to populate data)
• reload the page
• click on textarea edition
• click restore form
• check that the previously filled data is present

If this works correctly, then both TracWysiwygPlugin and DataSaverPlugin plugins are working.

Now try again, but when in the textarea edition change some of the data. Ideally when restoring back in textarea, you should see this modified data.

[Steve Strobel]

The "Restore Form" link is now lighting up for me; I don't know what has changed since I originally had that problem.

The test cases you described above work fine, but the following one does not:

• Navigate to a wiki page
• Press the "Edit this page" button
• If not already in WYSIWYG mode, select it
• Make some edits on the page
• Press browser's reload button (the changes disappear as expected)
• Switch to textarea mode
• Click "Restore Form" then "OK" (no change to form contents - nothing restored)
• Switch to WYSIWYG mode (the changes are not restored - expected since they didn't show up in textarea mode in the previous step)

[echarpentier@…]

I don't know for sure, but maybe the onbeforeunload event is not firing as it is in my own browser.

Can you try something like? =>

top.onbeforeunload = function() {
  alert('this is a test of onbeforeunload);
}

(I'm writing it quickly, might be some syntax error...)

[Steffen Hoffmann]

I've started to push DataSaverPlugin development (see #7516).

Please be aware of #3859, the 'sister' ticket of this one here. Maybe we could wake up this issue from sleep and make a joint effort to solve it.?

[Jun Omae]

Replying to hasienda:

Please be aware of #3859, the 'sister' ticket of this one here. Maybe we could wake up this issue from sleep and make a joint effort to solve it.?

Hi Steffen,

I added a few methods in r8691 and made the patch to solve. Please try tracwysiwyg r8691 or later and datasave-with-wysiwyg.diff​.

[Jun Omae]

Please try tracwysiwyg r8691 or later and datasave-with-wysiwyg.diff​.

The patch cannot be shown in my browser for reasons unknown to me. Please directly download the patch from datasave-with-wysiwyg.diff

[Steffen Hoffmann]

Replying to jun66j5:

Please try tracwysiwyg r8691 or later and datasave-with-wysiwyg.diff​.

The patch cannot be shown in my browser for reasons unknown to me. Please directly download the patch ![...]

I know, I already encountered this effect with diff parser unable to show diff several times before. Don't worry, I know, what to do.

I've never used TracWysiwygPlugin before, but will try now, since maintainership for DataSaverPlugin was passed to me these days. Well, user demand, and I understand it, even if I'm way to comfortable with the standard editor to use anything else on a daily base. Guess, I'm already too much of a text console guy. :-)

Anyway, thanks for you effort and reply. I'll report back my experience.