• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item5218: Wysiwyg editing often creates a bogus conflict and merge that destroys topic

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension WysiwygPlugin Urgent Closed   minor 4.2.0

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

Editing topics with Wysiwyg often often result in the person editing being told that his changed are in conflict and being merged causing the entire topic to be one big mess of ins and del tags and double text.

I cannot tell teh exact circumstances but in all the cases I have looked at logs and noone else was accessing the same topic at the same time.

I have spent hour in one single day helping people repair and in all cases I had to restore an older version of the topic. All editing was lost

-- TWiki:Main/KennethLavrsen - 07 Jan 2008

I have attached access log, twiki log, the topic in question.

The apache error log had two lines that may be of interest.

[Mon Jan 07 18:22:27 2008] [error] [client 132.156.91.85] Use of uninitialized value in scalar dereference at (eval 142) line 3.
[Mon Jan 07 18:22:27 2008] [error] [client 132.156.91.85] Use of uninitialized value in hash element at (eval 142) line 3.

That is all it says. No mention which file which is unusual.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

How do I reproduce the problem? I need to be able to reproduce it in order to debug it.....

CC

I have tried myself many times.

I keep on begging for the guy that did it 4 times to reproduce it for me but that team has been extremely busy.

Did the errors in my log say you anything. Any idea where they come from and why Apache did not list which file that failed??

-- TWiki:Main.KennethLavrsen - 14 Jan 2008

Guesswork on: Usually the ins/del tags shows up when conflicts are inside "special" markup - headlines, verbatim, blockquotes, etc. Standard text paragraphs are handled fine in my experience.

Perhaps formatting was changed for a large part of the document, perhaps there was cut'n'pasted some near-parsable content (leaving an open tag of some sort) into tiny from another (wysiwyg/text)editor or .. something similar?

-- TWiki:Main.SteffenPoulsen - 14 Jan 2008

Just happened again to another topic on the Motion TWiki.

Same symptom. I am embarrassed to release TWiki with this error. How many topics out there will be totally molested before we have a 4.2.1 out?

-- TWiki:Main.KennethLavrsen - 15 Jan 2008

I have uploaded all the relevant files from this 2nd time this happens in one week on a TWiki where people edit a few times a day.

-- TWiki:Main.KennethLavrsen - 15 Jan 2008

Looking at the log it seems strange that in some cases in the access log the rest script is called without the browser being authenticated.

Do we have conditions where the rest script is called in a way that the browser does not identify the user?

Can the conflict be a conflict between a virtual guest and the user himself?

It is clear that in the dv4linux case the user went through many steps where the rest script was called.

Look at the access log the line 84.167.232.53 - - [15/Jan/2008:22:30:23 +0100].

Why is this call to rest without the user name in the log? That means the browser called the rest script without the auth info. And we also see the return code which is a 401 instead of a 200. A 401 is the "Unauthorized" message.

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

I have been sitting playing with jumping fast through pickaxe and back to Wysiwyg. And I managed to get the two rest scripts to hang.

Maybe this is what happens? And then the user gets desperate and escapes away?

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

If the error is related to the pickaxe then we should remove the feature in 4.2.0 and add it later in 4.2.1. But I am not sure. I have massaged the above described case and it is hard to reproduce.

I notice in IE that you get Javascript errors quite often. Especially when you pickaxe to TML mode and start editing.

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

Just got an error "[Wed Jan 16 01:31:03 2008] [error] [client 192.168.1.9] Premature end of script headers: rest, referer: http://merlin.lavrsen.dk/twiki42/bin/edit/Myweb/LongTopic?t=1200443446" when trying to edit a topic.

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

Before anyone thinks that the reverting Item4946 may fix this then note that I had seen this error 3-4 times before I checked in the utf "fix" on the 08 Jan 2008. So even though the Item4946 code causes rest to fail, it cannot be the root cause for this bug.

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

Some additional info. I asked the editor of the dv4linux case to give a statement to what he did. It adds a little more info to the picture. He has used preview and he has used going back and forth using the browser back and forth buttons. A normal behavior for someone not familiar with a new user interface. And a behavior us old timers do not have. Here is his statement

I don't remember the exact sequence, but it went like this:

  • I made some additions to the dv4linux entry
  • To check the appearance, I clicked 'preview'
  • In preview, I found an error and wanted to fix it. In contrast to other wikis, TWiki didn't show a button 'back to edit', so I used the browser's back button.
  • I fixed the error, clicked preview, found another one, clicked browser's back to edit again.
  • select raw edit mode to fix the wrong formatting I saw in preview, clicked preview, found another one, clicked browser's back to edit again.
  • Iieeek, all my edits are gone!
  • clicked browser's forward, looks good, my edits are still visible in the preview
  • clicked 'save'
  • got a screen 'please confirm the changes', displaying diffs to the previous version. But, NO hint how to confirm/reject the diffs, wtf?
  • clicked several times forward/backward, hoping to find a hint how to either save my changes or to get to an edit screen with my changes

gave up, frustrated with TWIKI,

-- TWiki:Main.KennethLavrsen - 16 Jan 2008

ok, I have a theory that may work:

There is a biggo bug that crashes big time in MAIN, and silently sort of works in 4.2.0. There are 4 variables in edit.tmpl that are not expanded in Preview - ORIGINALREV (the most serious i think), TEMPLATETOPIC, SETTINGSTOPIC and NEWTOPIC.

This is an architectural flaw at the moment - it basically hopes that a coder will manage to have replace using regex's those values (as it seems to not be done using Pref's frown .

Part 2 is that the save code makes assumptions based on if originalrev is set... and when originalrev=%ORIGINALREV% it certainly is set frown .

thus, a merge could be triggered by a save that comes via preview.

If we combine this (somehow) with using browser back on FF, thus losing text , we could have a save that increases twiki's topic rev (either forcerev, or because this is the first time this user saved).

I've created a trivial TWiki:Plugins.DebugLogPlugin that Kenneth is running - Hopefully one of his users will trigger the problem, and we will have both all the POST params, and the parameters to mergeHandler.

In the mean time, I will look at commiting a simple fix to the Preview issue - though it would be better to confirm the problem first)

-- TWiki:Main.SvenDowideit - 17 Jan 2008

The fact that on FF browser back from preview from pickaxe seems to loose all changes is v awkward.

-- TWiki:Main.SvenDowideit - 17 Jan 2008

Item5258 is the change to fix the Preview html fields.

-- TWiki:Main.SvenDowideit - 17 Jan 2008

I managed to trigger the error. I write this NOW before I forget what I did. Will try to reproduce again.

  • Start with old topic that should not create a conflict because the lease time should be expired.
  • Use a topic that was last edited by someone else than the test person.
  • Operate as a test person who is not in the TWikiAdminGroup.
  • Use Firefox 2.0.0.11 in Windows XP as client.
  • Edit (wysiwyg)
  • Edit some text
  • Pickaxe
  • Wysiwyg button back
  • Pickaxe
  • Preview
  • Use browsers back button
  • Notice that the edits are lost
  • Use browsers forward button
  • Notice that you see the preview screen with your edits
  • Back again - edits still lost
  • Forward - see the edits in preview screen again
  • Hit the Save and Continue button
  • I was now met by the message that there had been a merge conflict with the user that had saved the old topic 24 hours before.

-- TWiki:Main.KennethLavrsen - 18 Jan 2008

Managed to reduce the steps

Again the same starting point with old topic

  • Edit (wysiwyg)
  • Pickaxe
  • Preview
  • Save

It is the pickaxe -> preview -> save that is the trigger.

The fix Sven did in SVN Item5258 fixes the problem with the false conflict. But we still wonder why the whole topic became ins/del molested

-- TWiki:Main.KennethLavrsen - 18 Jan 2008

Assumed fixed.

-- TWiki:Main.KennethLavrsen - 23 Jan 2008

ItemTemplate
Summary Wysiwyg editing often creates a bogus conflict and merge that destroys topic
ReportedBy TWiki:Main.KennethLavrsen
Codebase 4.2.0, ~twiki4
SVN Range TWiki-4.3.0, Sun, 30 Dec 2007, build 16120
AppliesTo Extension
Component WysiwygPlugin
Priority Urgent
CurrentState Closed
WaitingFor

Checkins

TargetRelease minor
ReleasedIn 4.2.0
Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip NetcamMjpegStreamDumps.zip r1 manage 21.5 K 2008-01-07 - 22:53 KennethLavrsen  
Texttxt NetcamMjpegStreamDumps_apache_access_log.txt r2 r1 manage 88.8 K 2008-01-17 - 00:56 KennethLavrsen  
Texttxt NetcamMjpegStreamDumps_twiki_log.txt r1 manage 3.7 K 2008-01-07 - 23:53 KennethLavrsen  
Compressed Zip archivezip mergebug_dv4linux.zip r1 manage 8.5 K 2008-01-15 - 22:25 KennethLavrsen Second time merge bug - all relevant files for debug
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2008-01-23 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback