Former title: RevCommentPlugin can cause forms to be cleared and other meta data to become garnage text.

The issue that Wysiwyg plugin is eating newlines. Especially related to HTML comments has been reported before.

I have had some serious issues where forms have disappeared. This has happened both on my Motion TWiki and at the Motorola TWiki.

I thought it was idiots that deleted the form fields.

But today I saw an error that clearly shows what the problem is.

When I have an HTML comment or some other entity that makes the Wysiwyg plugin eat a newline it sometimes eat the vital newline before the first META statement.

If this META statement is a Rev comment plugin meta the result is garbage like this.

<!-- DO NOT DELETE THIS COMMENT. 
...to this document is limited to the groups and people specified below because the document is part of the ISO9000 quality management system.
      * Set ALLOWTOPICCHANGE = Main.IceGroup, Main.PotSQAPolicyGroup
      * Set ALLOWTOPICRENAME = Main.IceGroup, Main.PotSQAPolicyGroup
-->%META:REVCOMMENT{comment_1=" " comment_2="Updated Expert review FTR findings 7,10,12 and 15." minor_1="1" minor_2="" ncomments="2" rev_1="53" rev_2="" t_1="1145977377" t_2="1145977645"}%</img></img></img></img></img> 

This issue destroys content and is so severe that I have to disable Wysiwyg immediately until it is fixed.

As a minimum Wysiwyg must never be able to eat a space before the META data at the bottom of the document.

And CC please revisit your decision to not do anything about eating newlines. People screw up topics all the time when there is no empty line before HTML comments and after HTML comments.

If you cannot reproduce it from the bug report, I will try and make a better test case later. I am at the office now and have other urgent work that I must do first.

KJL

I cannot reproduce this, on firsfox or IE. What other plugins have you installed that have beforeSaveHandlers?

CC

First thanks for looking at this one.

We have

• ActionTrackerPlugin
• CommentPlugin
• RevCommentPlugin
• WysiwygPlugin

Of these I would suspect RevCommentPlugin to be the most obvious candidate to be non compatible with Wysiwyg because this is the latest we added (After Steffen Poulsen had fixed them).

Even without the RevCommentPlugin the Wysiwyg plugin eats newlines and causes a lot of trouble for us. Maybe this problem in combination with Rev Comments makes the really bad result where we loose meta data in our topics incl. the entire contents of forms.

I will still try to reproduce it on my test server when I come home from work (which will be round 17-19 GMT).

KJL

Update.

On the Motion TWiki where I have seen forms being cleared for contents recently I can see that WysiwygPlugin was actually not used when it happened. But RevCommentPlugin had been installed. From my talking to myself on #twiki

[19:14] <Lavr> CDot. I am home. I assume you got my email that I sent from work.
[19:15] <Lavr> I have spent a couple of hours at the end of the day trying to make a topic that shows the problem. No luck. And I know - without case that makes trouble it is near impossible to fix it.
[19:16] <Lavr> I have seen the same strange thing a couple of times on my Motion TWiki. People have suddenly deleted the form contents for no good reason. I thought they were just idiots.
[19:19] <Lavr> This Motion topic is an example where the form disappeared. I need to find out if this topic was indeed edited with Wysiwyg. I should be able to see that from the Apache logs. Will take a while to dig out but I MUST know that.
[19:19] <Lavr> http://www.lavrsen.dk/twiki/bin/view/Motion/BugReport2006x04x07x164654
[19:19] <Lavr> Revision 14 and forward is where the form contents disappear and I have to re-enter it.
[19:22] <Lavr> The reason I attacked the Wysiwyg plugin in the bug report is that the garbage content looks exactly like the mess it often makes round HTML comment tags. But I have my doubts now.
[19:34] <Lavr> My Motion topic was not edited using Wysiwyg when the topic was saved and the form disappeared it seems.
[19:34] <Lavr> I would have seen a kupu in the URL
[19:36] <Lavr> No. That Motion bug report has never been edited using kupu. I will need to do the same exam on the Motorola TWiki.
[19:36] <Lavr> It puts the search light on the RevCommentPlugin as it looks like now.

Will be back with more.

Since this is probably not Wysiwyg I down classify this to Urgent and change the extention to RevCommentPlugin. Also changed title.

KJL

-- TWiki:Main.JadeCravy - 28 May 2006

I do not think so. Because 2371 is a duplicate of an earlier bug which was fixed. And my errors have happened AFTER these fixes have been implemented.

KJL

This bug has been cycling around accusing almost every extention for destroying data. Now I am changing it back to Core.

I have had several incidents at work lately. And I just had one this morning on my Motion TWiki.

The guy added just a few lines of text to a topic, he did not add a comment, he did not use Wysiwyg.

I have attached a zip file with the topic, its ,v file, the apache log, the error_log, and the twiki logs.

http://svn.twiki.org/pub/Bugs/Item2290/form-data-gone.zip

The error_log has no errors from the incident.

The access log shows that the guy hit edit. Then he had to authenticate. He edits with normal good old edit mode. And when he saves he has to do it twice.

At work we lost the form data again on an ISO9000 procedure. I will try and gather same kind of evidence on that. But can already say that the guy did not use Wysiwyg editing. Loosing the form data in our ISO9000 topics is critical because it means that it disappears from the index that searches for topics with a form with a field value "Procedure". So my QA department are turning negative against TWiki now.

We need to get this problem resolved. It is a pitty that it only happens maybe once a week so reproduction is very difficult. But the problem is there and severe.

I changed the bug item headline to reflect the real issue.

KJL

I have sent detailed logs and the topic from Motorola to Crawford. Cannot post it here since it is not for public viewing.

But the topic that lost its form data was edited with normal edit mode (not Wysiwyg). And in two cases it was seen that there is a POST log in Apache access_log but no SAVE entry in the TWiki log. In once case the version was never saved. In the 2nd case the guy probably hit back and tried again.

Error log is clean. Both Apache and Twiki warnings.

Since I disabled RevCommentPlugin I have not seen the problem again but more time must pass to be conclusive. But I did not see this issue before I installed that plugin either so there are some indications that this plugin can trigger the error even when people do not write any rev comment. Probably because it contains handlers that can trigger the error. If the error is in core other plugins with same handler could trigger the issue.

KJL

Item2324 just had its form cleared it seems (perhaps under similar circumstances)?

-- SP

Yes. Looks the same. And Bugs does not have RevCommentPlugin so it is a core issue. It seems the entire meta data is deleted. It is not just a form where going back in the browser cleared the fields. The meta data is gone it seems. That is also what I have seen at least 3 times now.

There is something really bad going on sometimes.

KJL

I looked at this again. And I notice that when I save a topic and preview first I actually POST (save) twice in a row with no view between. Can the issue be related to preview? We also have two save modes. Save and Quiet Save. I know one of the guys used Quiet Save because he thought that was how not to increate the version number. Maybe the combination of how you save/quiet save/preview is triggering the error?

KJL

One step closer.

In all 3 cases where we have logs of the event the user has previewed before saving. So we believe the form data is lost related to preview.

Problem is seen with both IE and FF as browser.

KJL

I have a topic where I have reproduced the issue several times.

I have attached a zip. http://svn.twiki.org/pub/Bugs/Item2290/LostForm.zip

The zip contains the topic and its ,v file PLUS a "view sources" of the preview page from the browser. The form used on the topic is also in the zip. Remember to add this form to WebPreferences first.

There is also a folder in the zip with the same topic BEFORE the save.

When I reproduced the bug.

• Edit - preview - Save and the form data is gone
• Back to preview I see the form in the preview - when I save again the form data is still gone. I could repeat this many times.
• Back and again back to the edit mode - and save without preview and the form is saved correctly
• Edit - preview - Save - and the form data is gone again.

Now we should be closer to a solution

KJL

It's a missing %FORMFIELD% in preview.pattern.tmpl.

ML

Added again (whoops!).

This bug was introduced after 4.0.2 (in r9843), closing it.

-- SP