Item12822: edit changes lost sometimes
Current State: No Action Required
Released In: n/a
Target Release: minor
There seems to be a transient error where edits are lost when editing via tinymce.
, but also could be related to the way NatEditPlugin
is triggering the
event to tinymce.
My understanding of this code still is not deep enough to see what's going on.
Besides not being able to find out about the circumstances which trigger the bug
[it seems to be a race condition of some kind. At least thats how the error manifests.
Please help by testing TinyMCE + NatEdit using the trunk versions and try to reproduce the error.
The error has been reported on a foswiki-1.1.9 + NatEditPlugin
from trunk. I was able to reproduce the error at least once using foswiki-trunk.
Actions to perform:
- set skin to natedit, pattern
- enable wysiwyg if disabled
- click on edit make some minor changes
- repeat 3+4 a couple of times until the error happens
- happens in modern browsers (i.e. chrome)
- Going back in the browser and saving again brings back the edits
- first switching to wiki-editor and back to wysiwyg seems to work around the edits being lost
- preview is missing the edit changes already even before clicking save
- 24 Mar 2014
I've spent another hour and wasn't able to repro the error on my localhost-install ... but found another slew of errors.
- 24 Mar 2014
Michael, Is this confirmed, and a release blocker for 1.2, or was this caused by my attempt at upgrading to TinyMCE
- 29 May 2014
This report is based on a client report who is seeing this frequently. However I really tried hard to reproduce it investigating the code, trying to just get a single incidence where changes get lost or even try to figure out the reason why that may happen.
The only wild guess I have is that there might be a race condition in the way tinymce has been integrated into Foswiki. The respective code doesn't feel
right in the sense that I could imagine how a race condition could happen.
To cure the problem the code in
probably needs a rewrite ... something not possible anymore in the scope of 1.2.0 I assume. I'd like to defer this to one of the following 1.2.x patch releases.
- 30 May 2014
I'm going to defer this to 2.1.0 minor release for now. If we have a patch we can evaluate for a 2.0.x patch, let's revisit it, but not for 2.0.1.
- 16 Jul 2015
This task is now a few months shy of 2 years in urgent status, without any reproduction. Removing the planned release and dropping back to normal to get it off the list of release blockers. Please bump the priority if there is a reproducible test case, or consider setting it to no action.
- 19 Dec 2015
- 24 Mar 2017 - 15:53