Item4737: Form fields not kept when going back after save failure (Firefox)

The context: editting a topic with a TWikiForm attached that has several mandatory fields.

When not all mandatory fields are entered, an oops will be shown with this text:

Topic Save Error

Could not save Data.Video0000000000.

The required field naam was not filled in.

Go back in your browser and insert information for all mandatory fields.

Now, when you 'go back in your browser', the information you entered before will be lost. Instead, the form fields will be reloaded from the topic (or cleared if you have just added the form to the topic).

In 4.1.2 we didn't have this behaviour. When you clicked 'back' you would find whatever you entered into the fields before hitting save.

-- TWiki:Main/KoenMartens - 27 Sep 2007

Changed to Engine. The "Release Blockers" page requires that a bug is either Engine or a default Extension spelled right to be shown, so we risk loosing an important bug like this if care is not taken to spell the extensions correctly. So if we do not know which extension keep it as Engine instead of inventing text.

Next release is a minor. 4.2.0 is a minor. 5.0.0 is a major.

This bug is a release blocker. If you loose all your form data when you submit and a mandatory fields is missing we will be lynched.

Same with preview. You have to be able to do a back in the browser and have the input you just typed both in topic and form.

-- TWiki:Main.KennethLavrsen - 28 Sep 2007

I just tested this

In IE it works

In Firefox the topic text is remembered when you use "Back" to go back to the edit window. But form field text is reverted to what you had before you edited.

I can confirm that the problem was not present in 4.1.2.

And I can add an important information: The problem is not present when you Raw Edit in 4.2.0. So this is a TMCE / Wysiwyg related problem. And again - only in Firefox. And it is both when you preview and go back, and when you go back after having forgotten a mandatory field. It is the BACK operation that is the problem.

-- TWiki:Main.KennethLavrsen - 28 Sep 2007

WysiwygPlugin plays no part in the browser; it is entirely server-side, so cannot affect this. Reattributed to TinyMCEPlugin.

CC

http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/states-form-elements-lost-when-using-back-button-firefox

Related? http://drupal.org/node/109941

-- TWiki:Main.CrawfordCurrie - 03 Oct 2007

After a long and difficult debug, I have isolated the problem. I believe it may be a bug in TinyMCE. I have asked for advice on the TinyMCE forum. Simple example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us">
 <head>
  <script language="javascript" type="text/javascript" src="file:///usr/local/tinymce/jscripts/tiny_mce/tiny_mce_src.js"></script>
  <script language="javascript" type="text/javascript">
    tinyMCE.init({mode : "exact", elements : "text"});
  </script>
 </head>
 <body>
  <form name="main" action="navigate away">
   <textarea id="text" name="text" >
Editor content
   </textarea>
   <input type="text" name="Textwithdefault" value="Some text" />
   <br />
   <input type="submit" value='Save' />
  </form>
 </body>
</html>

CC

This seems to be a known Mozilla bug. https://bugzilla.mozilla.org/show_bug.cgi?id=285730

TMCE forum discussion at http://tinymce.moxiecode.com/punbb/viewtopic.php?id=8710

CC

Good work! So there is probably not much we can do about this then..? Save from working around the bug by making some code of our own that saves/restores the fields , which is not really an option i think...

-- TWiki:Main.KoenMartens - 06 Oct 2007

The bug is not seen in normal edit. So surely there must exist a work around.

-- TWiki:Main.KennethLavrsen - 06 Oct 2007

There may be a workaround, yes. Without intimate knowledge of the internals of TinyMCE it would be hard to guess what it might be, though. The TinyMCE developers (Spocke) don't seem particularly interested, probably because no-one else has complained.

One possibility would be to put the formfields before the edit box, so that the order of the fields wasn't changed by the extra nodes added by TMCE.

I'd add a bug against TMCE but I've lost my sourceforge username, and have other things pressing on me ATM.

-- TWiki:Main.CrawfordCurrie - 06 Oct 2007

Changed the Component back to a value seen in the Release Blockers. Having NotTwiki and waiting for someone that never looks in our bugs database means hiding it under the carpet. We may as well delete such a report. This is show stopper defect! There is no way people can upgrade to 4.2 with the default editor not being able to remember field values when you go back.

If you look at our change request twiki application then we have 6-7 text area fields and a couple of mandatory fields. If someone with Firefox have edited a topic for 30 minutes and tries to save it - maybe even as a checkpoint - and he is refused because he forgot a mandatory field - and hits BACK and have lost all his work, then this user will dance on us sysadmin's balls.

If we have a mandatory field rejection feature - then dammit we cannot throw away all that people typed when they go back. It has nothing to do with which code has the problem. When I edit a form in non TMCE mode Firefox remembers the values. So it is possible to work around this. And we MUST find this work around - otherwise TMCE should not be the default editor in 4.2.0.

KJL

This is what I like to hear from a customer advocate!

-- TWiki:Main.ArthurClemens - 08 Oct 2007

How about having the mandatory check in Javascript so you cannot hit save, quiet save or checkpoint (grayed out) unless the mandatory fields are filled out? AND remove the preview button in TMCE edit mode (argument being that when you can see what you get why preview?). That could be an OK work around IMHO.

-- TWiki:Main.KennethLavrsen - 08 Oct 2007

Well, grayed out, wouldn't that be a bit confusing.. There should at least pop up some message saying 'hey, you did not fill in all mandatory fields'. Is a javascript alert ok? If so, i will try and get it implemented asap if the $dayjob allows.

-- TWiki:Main.KoenMartens - 12 Oct 2007

Use a javascript check on Save, and if an error: put an alert box (class "twikiNotification") at the top with the message "Please fill in all mandatory fields.".

-- TWiki:Main.ArthurClemens - 12 Oct 2007

Javascript alert is a fine solution

-- TWiki:Main.KennethLavrsen - 12 Oct 2007

One thing though, i'll probably be adding a new string for the alert, so unless i can reuse one of the existing strings from the oops i'll be breaking string freeze

-- TWiki:Main.KoenMartens - 13 Oct 2007

Done. If you can move the alert string into templates, so much the better.

This is an adequate fix for 4.2, though i am moving it too Normal status and marking it waiting for feedback from the FF peeps.

-- TWiki:Main.CrawfordCurrie - 13 Oct 2007

What happened here???

Topic is toast and my last note deleted?

-- TWiki:Main.KennethLavrsen - 14 Nov 2007

Item4570 appears to have been hit by the same formatting glitch.

-- TWiki:Main.SteffenPoulsen - 14 Nov 2007

For the record. Firefox 3.0.1 still has this problem.

-- TWiki:Main.KennethLavrsen - 26 Jul 2008

Still having this bug in FF 3.0.5

How about looking for a work around? I do not see any signs on the Firefox report that anyone is even looking at this

The Mozilla report is Mozilla Bug Report

Putting back to New

• KennethLavrsen - 24 Dec 2008

I don't believe there is a realistic workaround. The problem with FF also affects a bunch of other applications, including validation, and has done for quite a while. It requires FF to fix it.

-- CrawfordCurrie - 30 May 2009

I don't understand why we're keeping this bug open. FF hasn't done anything in 4 years, so I doubt they ever will, and as Crawford said, there is no real workaround we can do. Removing the FF bug from the waiting for list, and setting Crawford and Kenneth. Thanks to decide what to do with it.

-- OlivierRaginel - 04 Jun 2011

We could potentially utilise local browser storage, as utilised in the TMCE autosave-("draft") feature. It needs somebody to do the work.

-- PaulHarvey - 04 Jun 2011

Or someone could contribute a fix to the Mozilla project. Again, it requires someone to do the work.

Closing the bug doesn't get it fixed. And we are waiting for Mozilla (or someone to contribute a fix). It's a bug; it's still there; it needs to stay open.

-- CrawfordCurrie - 28 Jun 2011

I think that we can close this. I've confirmed correct operation on trunk.foswiki.org:

• Forced my login to use Wysiwyg on Tasks web by finalizing NOWYSIWYG=0 in my user profile.
• Created a new task, saved
• Edited task - Got Wysiwyg editor
  • Edited form, blanked out title (will cause missing field error_
  • Set a SVN rev to verify that form data was preserved
  • Modified the topic text to verify that TinyMCE data was preserved
• Saved task
  • Got confirmation error - confirmed it
  • Got for error
  • hit back button.
    • TMCE restarted and showed the expected text
    • Navigated to form, SVN rev was still present

So with firefox, form validation and across validation errors, everything was saved.

Setting to no action. Please reopen if problem recurs.

-- GeorgeClark - 12 Jan 2015