on Bugs:Item5006 I broke the lock when Crawford was editing. I only made a small change on one line, from:
I figured that Crawford would add at the end, so breaking the lock would be OK. When Crawford saved his changes we got this topic change:
This is urgent, but should not block the rc1 release.
- 25 Nov 2007
I saw this too, and corrected the topic. I have a horrible feeling it's a result of us both using WYSIWYG, but I won't know without a lot more research. If anyone is able to reproduce the problem consistently, that would be most helpful. I will not be able to look at it myself for at least a week.
- 25 Nov 2007
I have reproduced it.
I used FF as A
I used IE as B
None of the users are admin.
A edits, B breaks lock and also edits, A saves, B saves and sees warning. Here I have seen A's save delete
A edits, B breaks lock and also edits, B saves, A saves and sees warning. In this case the topic was totally crashed and even the user interface outside the topic area is goofy.
In both cases I edited a very long topic. One added a few words in the beginning. The other at the end. No risk of merge conflicts by overlap.
So yes, merge does not work with TMCE at all.
In the total goof case I lost 80% of the content. Formatting was poor. And all remaining headlines doubled.
- 28 Nov 2007
Allocating to Tiny MCE, though this may be a problem with all Wysiwyg.
OK, I've tried every possible variation of trying to create a conflict using your test topic, and I just can't. I suspect it may be arace condition, but until someone shows me how to reproduce it reliably, there's not much I can do....
- 04 Dec 2007
I can still consistantly reproduce it.
Some further observations.
Aopen Bopen Bsave Asave means total destruction
Bopen Aopen Asave Bsave means A's saving is lost.
When I edit I always write a few words just below the headline 1.1 Purpose in the first browser and at the far end in the 2nd browser that opens the doc. I have not tried if this makes a difference - just - that is what I do. But it means a lot that it is FF that opens first and saves last.
My next investigation is to see what difference it makes what plugins I have active and I also want to try different topics. One plugin that should be noticed is RevCommentPlugin
. There is also a plugin called KennethPlugin
but that I know was not active when I showed the error the first time and it only registers a couple of tags and uses no handlers.
- 04 Dec 2007
After having turned off plugins and enabled them again the problem of total destruction is gone but the merge still does not work. Ie. the A B B A sequence means all B does is lost.
I also notice that when B (IE) saves the IE6 reports JS error but the topic looks correct. Until B saves.
I need to find out how to get back to the mode where things were destroyed because that bug is for sure luring still.
Maybe the bug that makes the merge not work is the same that can destroy topics. The merge bug I can reproduce any time, and you
- 05 Dec 2007
I have reproduced the problem again. This time with a small simple topic with just some 15 lines of plain text.
First time with all my plugins I got an entire section of text repeated twice and again the ABBA sequence meant that B's changes were lost.
With only default plugins a small change. Now I get a conflict at the end. TWiki inserts some bold Conflict tags at the end. But I should not have a conflict at the end because each time I test I always let A add text at the top and B add text at the bottom.
In one test I saw B's text added but the newline before the text was eaten.
There is something mysterious going on with the merge when you use TMCE as editor.
- 05 Dec 2007
I have reproduced the problem again where a section is repeated twice.
And this time with only default plugins enabled so it has nothing to do with plugins. But it seems the total destruction modes are more frequent on a virgin topic.
The latest test was this topic.
- First B in IE creates the topic except the ending "IE endtext" and saves it.
- Then A with FF edits the topic and add the text "FF start text" before the entire topic but does not save yet.
- Now A with IE edits and is warned as he should and edits anyway.
- A adds the paragraph "IE endtext" at the end of the topic and he saves. Topic looks good at this point.
- B saves. He gets a warning that text has been merged. The result is the first section of text in the original topic is inserted in front of the "FF start text" and the entire old topic is wrapped in a pair of ins tags which makes the topic appear underlined in IE.
I can repeat these errors again and again. Crawford you should be able to also.
Of other notes, I use FF 188.8.131.52. IE 6.0.2900. TWiki runs with Apache Login with login IDs but with standard htpasswd password manager. Last test was with the default set of plugins activated.
- 05 Dec 2007
This is confusing. I numbered your steps for clarity.
At step 3 A edits the topic in IE. But in step 5, B saves in IE. How? B is not editing the topic. In step 4, A adds the text "IE endtext". In IE or in FF?
I suspect you have your A's and B's confused. Please be precise, I need to know exactly
what you did.
It looks like the problem is that the merge is done before
the afterEditHandler is called. It was done this way so that plugins would be called on the post merge text, but in the special case of WYSIWYG that text needs additional processing before a merge can be attempted.
- 08 Dec 2007
Yep, that's confirmed. The merge is done on the HTML. It needs a new plugin handler to solve.
Ok, that's fixed, though it does highlight a deficiency in the merge. The merge is designed for merging text files, and as such merges blocks delimited by newlines. That works fine as long as you use a lot of newlines in your text, but WYWISYG tends to minimise newlines (it just doesn't know where to put them). Also, you might have old text which has a lot of newlines, and edit it in WYSIWYG. A merge will be confused by all the old newlines and will show a lot of differences that - visually - don't exist. I don't have an answer to this problem.