Item78: Form is emptied on the user homepage when using preview
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
--
IngoKappler - 04 Nov 2008
Something similar reported in
Item5183. --
ArthurClemens - 04 Nov 2008 - 23:55
I bet it is related to Firefix only. We had to remove preview in Wysiwyg in 4.2.0 because preview meant loosing all formfield values when you hit back. They would revert to the previous values. There may be a work around for this. It does not happen in raw edit in pattern skin. We just never found such work around. --
KennethLavrsen - 05 Nov 2008 - 00:12
Steps to reproduce:
- Connect to your user page with Firefox or IE on nextwiki.org
- Update the form fields via the RichTextEditor
- Preview the result
- Save on the preview page
Result: All form field values disappear
Expected: Same content should be shown after saving as on the preview page.
Using the IE engine from within Firefox (IE tab) didn't help. I now also retested it with IE 7.x and the form fields are emptied too! So it does not appear to be a Firefox only issue. The issue is clearly related to using the preview functionality. --
TWiki:Main.IngoKappler - 07 Nov 2008
My guess is that a hidden input field is missing from the preview template.
--
ArthurClemens - 07 Nov 2008 - 14:44
Shouldn't we be able to close this or at least change the state? I am not sure so someone else should confirm.
--
IngoKappler - 03 Jun 2009
It is for sure not in the released code for Foswiki.
In raw edit it works.
In Wysiwyg the preview is disabled.
My guess is that it was the rich text editor used in Nat Skin that we had on the foswiki site in November that caused this - and the reason is the same that triggered us to remove preview from Wysiwyg.
Firefox cannot remember text fields when you return if you have a lot of JS in the page or whatever it is that triggers the bug.
It is a know bug that Firefox developers does not seem motivated to fix.
The only way this can ever be closed is if the author of the Nat skin rich text editor finds a work around for the problem. It is not likely an error in the authors code. It is Firefox.
--
KennethLavrsen - 03 Jun 2009
Can't reproduce on the latest release of
NatEditPlugin.
--
MichaelDaum - 22 Dec 2010