You are here: Foswiki>Tasks Web>Item2453 (20 Feb 2010, PaulHarvey)Edit Attach

Item2453: Form data lost (fails to save) via ?action=form

pencil
Priority: Urgent
Current State: Closed
Released In:
Target Release: n/a
Applies To: Extension
Component: NatEditPlugin
Branches:
Reported By: PaulHarvey
Waiting For: Main.MichaelDaum
Last Change By: PaulHarvey
Steps to reproduce:

  • Access a topic that has a form already attached to it via /bin/edit...?action=form appended, or use the "edit form data" widgeth in the top-right area of the form that's displayed in view mode.
  • User is taken straight to the form tab of the editor (actually, the topic edit tab is absent, by design)
  • Make some changes to form data.
  • Press save

At this point, there is a defect:
  • user is taken to the edit script again, except this time with the topic editor open, and the form tab has lost all the data that was entered previously.

Expected behaviour:
  • User should be taken (generally) back to view script, where he/she can see the changes they made saved to the topic.

Seems to be caused by a crazy jQuery bug.

$('#EditForm') simply fails to find the edit form element.

Instead, pass document.getElementById('EditForm') into jQuery as the selector.

Very, very weird. There are som slight XHTML validation issues, I wonder if this is upsetting jQuery.

Confirmed on FF 3.0.12 and IE8.

Need to make a new release, so set waiting for Michael.

-- PaulHarvey - 04 Dec 2009

The replacement of #EditForm with the equivalent getElementByID() can't be correct.

Can you further describe the circumstance when this happens:

  • are you using TinyMCEPlugin
  • which skin are you using
  • are there any other view or edit templates coming into play?

Thanks for tracking this down.

-- MichaelDaum - 04 Dec 2009

Ok, I must be going crazy. I swear that every time I would break on that $('#EditForm') line, running the jquery statement in the console failed to give me any results, whereas getElementById('EditForm') did.

Who knows, firebug is kinda buggy... Anyway, you are right, it wasn't JQuery's fault.

The improved check for presence of TinyMCE fixes the problem by itself. With ?action=form TinyMCE loads but does not start (there is no valid textarea to hijack).

The browser must have been simply following the <a href="../bin/edit.." link in the save button, because the JS thread was stopped with a "null object has no member onSubmit" error which disappeared too fast for me to see.

I should have used the browser's error console which preserves errors between page views, instead of firebug's console..

-- PaulHarvey - 05 Dec 2009

Don't trust anybody that swears wink

-- MichaelDaum - 07 Dec 2009

This is ready for release.

-- PaulHarvey - 05 Feb 2010

Fix from PaulHarvey: download http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/edit.js and http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/edit.uncompressed.js replace those files in /pub/System/NatEditPlugin

-- IngoWolf - 06 Feb 2010

ItemTemplate edit

Summary Form data lost (fails to save) via ?action=form
ReportedBy PaulHarvey
Codebase trunk
SVN Range
AppliesTo Extension
Component NatEditPlugin
Priority Urgent
CurrentState Closed
WaitingFor MichaelDaum
Checkins distro:df7d7201abe6 Rev 5723 not found
TargetRelease n/a
ReleasedIn
Topic revision: r12 - 20 Feb 2010, PaulHarvey - This page was cached on 08 Dec 2016 - 03:13.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License