Last modified: 2010-05-15 14:36:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 56 - section edits sometimes wrongly merged in edit conflicts
section edits sometimes wrongly merged in edit conflicts
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: High major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 69 649 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-08-15 15:59 UTC by elian
Modified: 2010-05-15 14:36 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch to fix bug (2.08 KB, patch)
2004-09-07 22:18 UTC, Wil Mahan
Patch against MediaWiki 1.3.3 (2.04 KB, patch)
2004-09-10 05:33 UTC, Wil Mahan
Patch against REL1_3 (2.30 KB, patch)
2004-09-22 16:48 UTC, Wil Mahan

Description elian 2004-08-15 15:59:46 UTC
Should be a known issue, but I couldn't find a bug report:

If you insert a new section (say number 5) and someone is editing section 12
below and saves it, no edit conflict is given, section 12 is just inserted
another time (see for examples and
testing). There are other reports that sometimes sections are deleted
unvoluntarily in similar cases.

Workaround: fix page later manually, make problem known in the editing FAQ.
Comment 1 Addicted 2004-08-30 19:05:39 UTC
This problem is a major one, if it isn't noticed immediatly! (Or do some users just don't care?)

e.g. look at
there wasn't noticed from August 30 11:01 till 20:30, while several changes where made.
(I noticed it only because it happened again while I was editing the page!)
Comment 2 Rowan Collins [IMSoP] 2004-09-02 23:07:43 UTC
I suspect this is related to or the same as bug 275 (which is older than it
seems; I just migrated it from SourceForge). However, given that that bug
diagnoses it as a problem of conflict-with-self, and this suggests conflict
between users, I won't mark it as a duplicate just yet, as it may be that there
are two bugs here, making each other worse.
Comment 3 Wil Mahan 2004-09-07 22:18:38 UTC
Created attachment 28 [details]
Patch to fix bug

Here is a patch that attempts to fix the problem by merging section edits into
the revision at the time the edit form was loaded, rather than always using the
current revision.
Comment 4 Wil Mahan 2004-09-07 23:05:40 UTC
Please note that the problem pointed out by "Addicted" might be a different bug;
as far as I could tell that problem duplicated the entire contents of the page,
rather than one section. My patch aims to fix a problem wherein sections are
duplicated or dropped. Similarly, I'm not sure that bug 275 is the same bug. But
I am fairly certain it will fix the problem described by the bug reporter, elian.

The problem my patch addresses can occur either in a conflict between two
different users, or in the case of conflicting submissions by the same user. It
can be difficult to predict what the the edit conflict merging code might do
after the article text gets mangled. Thus I can't rule out the possibility that
these problems are related.
Comment 5 Wil Mahan 2004-09-08 13:02:18 UTC
*** Bug 69 has been marked as a duplicate of this bug. ***
Comment 6 Wil Mahan 2004-09-10 05:33:34 UTC
Created attachment 30 [details]
Patch against MediaWiki 1.3.3

I am uploading a patch against MediaWiki 1.3.3, since this seems to be a
serious bug that might be worth fixing in the stable branch.
Comment 7 Brion Vibber 2004-09-11 11:25:05 UTC
Wil, can you provide a sequence of edits which reproduces the bug and which is
fixed by the patched code? These section things are tricky and I just want to
make dead sure it's nailed. :)
Comment 8 Wil Mahan 2004-09-11 18:59:45 UTC
Sure. Please look at . I initially created
a page with sections 1-4, filled with some dummy text. Then I initiated two
section edits at the same time, for section 2 and section 4 (i.e. I loaded both
section edit pages before submitting anything else).

On the section 2 edit page, I added a new section above section 2 and submitted.
As you can see from the second revision in the page history, everything works
fine to this point. But then in the section 4 edit form, I added some text to
the section (although the specific nature of this edit isn't important for
reproducing the bug; any changes to the text are sufficient).

Note that when I submit the form for section 4, section 3 gets dropped entirely,
while the article now contains copies of section 4 both before and after my
edit. This is because when I submit section 4, the updated text is inserted into
the article based on the section numbering of the most recent revision, rather
than the section numbering at the time I loaded the edit form.

This bug can occur because of a self conflict, as this test case demonstrated,
or due to a conflict between two different users. Let me know if you have any
other questions.
Comment 9 Wil Mahan 2004-09-14 05:49:52 UTC
In case my previous explanations weren't clear, here's some pseudocode
describing what my patch does. When a user submits edits to section number
"N" of an article, the current code (without my patch applied) roughly
does the following:

 // start pseudcode

 get_current_text_of_article() //might have changed since we started editing

 // nothing below here is changed by my patch
 // code to update section

 // merge if necessary
 if (the_article_has_been_modified_since_the_user_started_editing) {
   if the_last_edit_was_by_the_same_logged_in_user() {
      // self-conflict; just overwrite the old revision
   else {
     //uses the "diff3" program
     if (the_merge_succeeded) {
     else {
 else {

 // end pseudcode

I simplified some things, but that should be the general idea. The
problem with the above is that the section updating code does not
take into account whether the article was modified since the user
began editing. So the "delete_section_N" part could end up deleting
the wrong section, which the merging code can't fix because in
effect, it's the same as if the section were removed by hand. The
deletion/insertion of the wrong section is merged into the final

My patch only changes one thing: instead of
it effectively does

I think it is clear that even when someone else has submitted changes
while we were editing, those changes will still get merged in
because the most current (most recent) revision is always used for
the merge.

Hope I didn't just add to the confusion. :)
Comment 10 Wil Mahan 2004-09-19 21:00:38 UTC
I commited my patch to HEAD. If no problems turn up I will see about applying it
to REL1_3.
Comment 11 Wil Mahan 2004-09-22 16:48:43 UTC
Created attachment 47 [details]
Patch against REL1_3

Updated patch against REL1_3 that fixes a warning. If possible, I would like to
have this applied to 1.3 to see if it helps with bug 275.
Comment 12 Anthony 2004-10-05 15:39:54 UTC
This may be related to bug 649.
Comment 13 Wil Mahan 2004-10-06 03:28:18 UTC
*** Bug 649 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2004-12-11 23:18:22 UTC
1.4 imminent, closing as FIXED.

Note You need to log in before you can comment on or make changes to this bug.