arnomane wrote:

I noticed this bug again this time in the english wikipedia. Her a link to the diff (note the two subsequent edits of user Nichalp,
which where related to that problem):
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&diff=9159759&oldid=9155917

The user wrote on my personal talk page after this edit: "The fault lies with Wikipedia. Apparently I was trying to reply to a
posted message, and my browser didn't give me any confirmation so I pressed the "Save Page" repeatedly."

Daniel Arnold (Arnomane)

zigger wrote:

All the examples were edits within a couple of minutes of each other.
This might be due to database replication lags, causing the edit text-box to be
loaded with an older revision from a database slave, resulting in the missing
edit being lost when saved.

If you notice this, please repeat the missing edit to the article, crediting the
original author in the edit summary.

arnomane wrote:

Well I think it is also important to note the small changes in the timestamp of the signatures. This means in the last example:
User:Nichalp had overwritten his text (which he saved previously and which was the same despite the ~~~~ wich got expanded to
another timestamp) and the text of User:Aromane (me).
It must have happend this way:
a) User Nichalp opened a section of the page for editing
b) After that user Arnomane also opened another section of the page for editing and saved the edit after a short time
c) User Nichalp saved his edit and since there was no edit conflict between the two section edits there didn't show up one and so
user nichalps cange was saved first time.
d) User Nichalp didn't get any feedback in the browser so he pressed again "save page" And now strangely not only the section but
the whole article got overwritten by the version from the point when he began editing plus his edit. And since it was a later time
his timestamp changed.

With the other two edits it was similar.

arnomane wrote:

Finally user Avatar in German Wikipedia showed me an easy way how to reproduce this bug. It has nothing to do with reload issues and
delays in browser display as I assumed first. It is much simpler:

I created two sections in an article (sandbox in German Wikipedia), called "Sektion 1" and "Sektion 2" and gave them a small text
"1: Hallo" and "2: Hallo":
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=4387945

I opened "Sektion 1" for editing (section edit) in a new Window (window 1)

I opened "Sektion 2" for editing (section edit) in a second new window (window 2)

I removed the "1: Hallo" text in "Sektion 1" in window 1 and saved it.
So this ist the diff as expected: http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&diff=4387960&oldid=4387945

I added "3: Hallo" in "Sektion 2" in window 2 and saved it.
And now here is the mysterious diff with the bug:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&diff=4388174&oldid=4387960

You see the "1: Hallo" text is falsely readded to the text and so the previous edit got reverted by software although I did edit a
complete different section and only wrote "3: Hallo".

So I hope with this easy way of reproduction it is now possible that this nasty bug can be found and fixed in source code.

richholton wrote:

I'm not sure exactly how the section editing resolution is done, but this bug
seems to be directly related to the fact that edit conflicts between the same
user are explicitly ignored in the code. If a user saves twice from the same
loaded version of a page, the second save will wipe out the first. This is to
allow a user to save an edit, hit "back" in the browser, and make a different
change (presumably correcting the first change) without having an edit conflict.
We may need to rethink this particular feature...

arnomane wrote:

Okay it has something to do with with so susequent edits of the same user. With a trick I can now reproduce how you can
also delete edits of others by accident:

Again two sections:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=4394445

Open the "Sektion 2" section with browser A as logged in user for editing. (in this case KDE Konqueror browser and logged in me as
user Arnomane)

Open the "Sektion 1" section with browser B as logged in user for editing. (in this case Mozilla browser anonymous so not logged in
at the same computer)

Remove the "test 1" text in "Sektion 1" in browser B as anoymous user and save it, until now everything is okay; here is the diff:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&diff=4394459&oldid=4394445

Add "test 3" text in "Section 2" in browser A as logged in user (here Arnomane) and save it. Now this time here is everything okay
it doesn't overwrite the previous edit; see diff to previous version:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&diff=4394462&oldid=4394459

Now press the backwards button in browser A so that you get again the edit box (here still logged in as Arnomane) and add "test 4"
text and save it. And finally here the bug deletes the edit of the second user which was done in between (in browser B) and adds
falsely again the "test 1" text in the first section:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&diff=4394476&oldid=4394462

So here the software thinks that there is only an edit conflict with the user itself and thus explicitely ignores the change of the
second user and overwrites it.

So I think the basic idea behind that you ignore an edit conflict of the user with himself is a good thing but the actual solution
only works if you only edit the entire article, but with section editing it doesn't work. I think there is also a merge problem
with section edits. I hope this bug can be fixed very soon, as it is a lager problem in Wikipedia and has lead to many many bad
words of users that thought someone is censoring their edits (thats why I gave this bug the maximum vote)...

arnomane wrote:

Some more thoughts:
I think I know what the exact problem might be (without looking at the code):
*If two different users edit different sections their edits get normally merged since they don't conflict with each other.
*But if one user makes two subsequent edits they don't get merged but the second overwrites the first edit.
*So if there is a merge of the subsequent edits of one user as with the two different users and then ignoring a potential edit
conflicts of the user with himself there should be no unwanted deletion.

mdonn wrote:

On en.wikipedia I am "Too Old". I added text to Talk:TradeStation. I saved edit.
I re-edited, adding text to first edit. I saved edit. Now I see only first
version of text if I am logged in, but entire text if I am logged out.
Clearing my cache makes no difference. Restarting my browser makes no
difference. My browser gives following "about" information: "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv: 1.7.8) Gecko/rMW200505116d94 Firefox/1.0.4" --
mdonn@harbornet.com

wegge wrote:

We need to check if this is also a problem in HEAD. If it is, we should mark
this as a blocker agains the 1.5 release. I'll give it a shot, but I'm away for
the next two weeks. So if someone could take a before, it would be fine.

wegge wrote:

Why doesn't bugzilla do what it is told?

Is this just section edit conflict resolution, the same as bug 1601?

The descriptions don't seem to indicate any *disappearing* or *overwritten* edits, just new section
edits saved based from the wrong prior version.

arnomane wrote:

Yes #1601 is definitly a duplicate of this bug. The "deletion" and the "revert" to previous "version" are the same thing.

You name it as deletion of a previous edit in a talk page where you have separated blocks of edits (e.g. a vote with comment on
vote pages) or as a "revert" to a previous version in an article if you inserted or rearranged some stuff. Only the diff looks
because of the different edit structure a little bit different at the first view but it's the same bug.

rowan.collins wrote:

[Removing block on database replication tracker as the bug doesn't seem to need
lag as such.]

It's worth noting that this bug *doesn't* require section editting to be
involved - consider the following sequence:

1. user A starts editting a page
2. user B saves an edit adding to the bottom of the page
3. user A adds something to the top of the page and saves; diff3 merges the edits
4. user A resubmits the same edit; now the current version is by user A, so

diff3 isn't called, and the edits at steps 2 and 3 are ignored

The problem with trying to merge the two edits by the same user is easiest to
see if step (4) is instead "user A submits a slightly modified edit", in which
case the merge would fail - AFAIK, diff3 can't merge some chunks and ignore
others, so the only resort would be to have an edit conflict with yourself. Just
clicking the button twice *ought* not to produce an unmergable edit, but I'm not
100% sure that would always be the case. Even then, whether losing the ability
to go "save - oh, whoops, forgot to sign - stop, type, save again" without
getting a conflict screen is an acceptable price to pay, I'm not sure; Brion
says in bug 275 comment 6 that "we got a lot of complaints about that back in
the day".

Nor would it help, as I first thought, to check whether someone else has editted
*as well as* "yourself" since you clicked the edit link, because of the
possibility of editting two sections in different windows/tabs - indeed, if you
turned merging for edits by the same user on, users A and B in the example could
actually be the *same* user!

It seems to me that, unless someone comes up with a different technique, that we
have to choose between fixing this bug and retaining the ability not to
edit-conflict with yourself.

rowan.collins wrote:

*** Bug 1601 has been marked as a duplicate of this bug. ***

wegge wrote:

(In reply to comment #11)

Is this just section edit conflict resolution, the same as bug 1601?

No, it's actually two different bugs. The section editing conflict is one part,
but there is also a problem with the same user submitting an edit twice. In this
case, any conflict resolution performed on the first edit is silently discarded.

rowan.collins wrote:

(In reply to comment #15)

(In reply to comment #11)

Is this just section edit conflict resolution, the same as bug 1601?

No, it's actually two different bugs. The section editing conflict is one part,
but there is also a problem with the same user submitting an edit twice. In this
case, any conflict resolution performed on the first edit is silently discarded.

I don't think it's two bugs; a more accurate statement is that section editting
is one way of *triggering* this bug, but not the only way. In fact, it's neither
"sufficient" (you have to conflict with yourself *as well*) nor "necessary" (you
can create the same effect by manually editting different parts of the article);
in other words, it's something of a red herring - it's just the most likely way
of encoutering this bug "in the wild".

If you can give examples of situations which don't fit my basic steps in comment
13, I will of course stand corrected.

wegge wrote:

(In reply to comment #16)

(In reply to comment #15)

(In reply to comment #11)

Is this just section edit conflict resolution, the same as bug 1601?

No, it's actually two different bugs. The section editing conflict is one part,
but there is also a problem with the same user submitting an edit twice. In this
case, any conflict resolution performed on the first edit is silently discarded.

I don't think it's two bugs; a more accurate statement is that section editting
is one way of *triggering* this bug, but not the only way. In fact, it's neither
"sufficient" (you have to conflict with yourself *as well*) nor "necessary" (you
can create the same effect by manually editting different parts of the article);
in other words, it's something of a red herring - it's just the most likely way
of encoutering this bug "in the wild".

If you can give examples of situations which don't fit my basic steps in comment
13, I will of course stand corrected.

I cannot give you a way of reproducing it right now. However, I've seen some
real strange results by not skipping the conflict check, even if the same user
is the last editor. At one point I managed to get the entire page pasted into
one section, so there is something wrong with section editing as well.

On the matter of resubmitting an edit twice, I think that the easiest way of
solving the problem, is to pass a token with the edit form that can be used for
one submission only. This will at least fix the problem of editors using their
browser history to resubmit something instead of making a new edit.

river wrote:

(In reply to comment #17)

On the matter of resubmitting an edit twice, I think that the easiest
way of solving the problem, is to pass a token with the edit form that
can be used for one submission only. This will at least fix the
problem of editors using their browser history to resubmit something
instead of making a new edit.

this will break if the user makes an edit, clicks back to correct a
mistake, and resaves.

wegge wrote:

(In reply to comment #18)

(In reply to comment #17)

On the matter of resubmitting an edit twice, I think that the easiest
way of solving the problem, is to pass a token with the edit form that
can be used for one submission only. This will at least fix the
problem of editors using their browser history to resubmit something
instead of making a new edit.

this will break if the user makes an edit, clicks back to correct a
mistake, and resaves.

I know, but this user behaviour is precisely the problem in the first place.

rowan.collins wrote:

(In reply to comment #17)

I cannot give you a way of reproducing it right now. However, I've seen some
real strange results by not skipping the conflict check, even if the same user
is the last editor. At one point I managed to get the entire page pasted into
one section, so there is something wrong with section editing as well.

This sounds suspiciously similar to bug 275 - probably the most irritating, most
intermittent, and least well-defined and diagnosed bug in the whole of
MediaWiki's history. For all I know, that bug and this are very closely related,
but given that we seem to have a pretty tight definition of *a* particular bug
on this page, I'd favour keeping to that one issue here rather than confusing
the issue with events that clearly *aren't* the same.

rowan.collins wrote:

(In reply to comment #19)

(In reply to comment #18)

this will break if the user makes an edit, clicks back to correct a
mistake, and resaves.

I know, but this user behaviour is precisely the problem in the first place.

Again, I refer you to bug 275 comment 6, where Brion states:

The purpose is so that someone who saves an edit, clicks "back", makes another

change, and clicks "save" again

won't receive an edit conflict message. We got a lot of complaints about that

back in the day.

So this isn't, per se, the problem (it is, quite literally, not a bug but a
feature) but as I said in comment #13:

It seems to me that, unless someone comes up with a different technique, we
have to choose between fixing this bug and retaining the ability not to
edit-conflict with yourself.

dragonmaynard wrote:

hello,

i am quite suspicious that i have noticed a new bug, but i found this bugreport
which at least deals with the same issues and has gotten recent activity.
therefore, i start here and will be happy to open a new fellow as soon as i am
prompted to do so.

this morning i made a minor edit to a page that i had last edited last week.
that prior edit (not a minor edit) was the most recent edit to the page. after
completing today's edit, my contributions page shows two separate edits, one
from 2005 june 16, and one from 2005 june 22.
[http://en.wikipedia.org/w/index.php?title=Special:Contributions&target=Burgher]

however, the history of the edited page shows only one edit, with the date and
tag of my recent minor edit.
[http://en.wikipedia.org/w/index.php?title=Berry&action=history]

if you choose the diff for the edit listed on the history page, you get the
changes from both of my edits together. if you choose the diff for either edit
listed on my contributions page, you get the diff you would expect.

here is where it really starts to hurt my head. if you go to the history page,
where it erroneously lists just the one edit, and get that diff where it shows
the changes from both edits, _and then_ move two pages back in the edit history
followed by one page forward again, you see the mysterious hidden edit from 2005
june 16.

ow, my head.

help!

(obviously this is relatively minor, but just as obviously it must be some sort
of microbe.)

dragonmaynard wrote:

er, you only have to go back one and then forward one to get the mysterious edit
to disappear. i think this means that the error is with the history page code...

dragonmaynard wrote:

s/disappear/appear/

alphasigmax wrote:

(In reply to comment #22)

this morning i made a minor edit to a page that i had last edited last week.
that prior edit (not a minor edit) was the most recent edit to the page. after
completing today's edit, my contributions page shows two separate edits, one
from 2005 june 16, and one from 2005 june 22.
[http://en.wikipedia.org/w/index.php?title=Special:Contributions&target=Burgher]

however, the history of the edited page shows only one edit, with the date and
tag of my recent minor edit.
[http://en.wikipedia.org/w/index.php?title=Berry&action=history]

if you choose the diff for the edit listed on the history page, you get the
changes from both of my edits together. if you choose the diff for either edit
listed on my contributions page, you get the diff you would expect.

here is where it really starts to hurt my head. if you go to the history page,
where it erroneously lists just the one edit, and get that diff where it shows
the changes from both edits, _and then_ move two pages back in the edit history
followed by one page forward again, you see the mysterious hidden edit from 2005
june 16.

ow, my head.

help!

(obviously this is relatively minor, but just as obviously it must be some sort
of microbe.)

It's database lag. Check it again. ~~~~

zigger wrote:

(In reply to comment #22)

i am quite suspicious that i have noticed a new bug, but i found this bugreport
...

This particular issue (missing most recent history) is different from the main
topic of this bug, and has already been reported as bug 1286. As Alphax states
in comment 25, missing most recent history is a transient problem due to
database lag. The history for that page looks okay now.

river wrote:

*** Bug 2712 has been marked as a duplicate of this bug. ***

Yesterday, I submitted a hypothesis and potential simple fix to bug 275. Since this bug comes from
basically the same part of the code, I thought I would think about it as well. (Not to mention the fact
that I got bugged by this just this morning.)

Most of the comments here seem to be right on the money. The problem is that when checking for an edit
conflict with oneself there are no other checks for edit conflicts with other material added since the
editor started.

In other words, when I am editting, all my edits are made in reference to the version I opened for editting
(call it version 1). Then while I am editting someone else makes some changes and saves as version 2. Now
when I save the first time, it notices that someone else has made an edit and tries to merge them. If this
succeeds, then we arrive at version 3A. Now, being dumb, I notice that I misspelled "celebration", so I hit
the back button, quickly fix it and save again. This time the software notices version 3A, sees that I also
made that edit and consequently, it cancels all edit conflicts. Since I used the back button, my edit is
still based on version 1. So this time when it saves, the conflict with version 2 is ignored. Hence,
whatever changes which were made in that version are dropped from the new version 3B.

For the curious, this all happens in EditPage.php:editForm

So how can it be fixed? Well rather than simply canceling the edit conflict if the last user to edit was
the same user as is saving now, it needs to query the database for any edits by users that are not me that
occured later than the time I opened the edit form, and respond appropriately.

If this set is empty (i.e. no one has been editting but me), then everything is good and it is okay to
cancel the conflict. Otherwise, you need to deal with those other edits. Notice that 3A in the sequence
above was created just fine by a merge on 2. This suggest to me that the best approach is simply to take
the most recent version of the article creating by someone else and treat that as the current version of the
article. Let the software attempt to merge on that. If it does, then everything should be fine. If not,
then it will throw an edit conflict window between the last non-me edit and my present edit.

So, to outline my suggested strategy, when checking for a self edit conflict in

EditPage.php:editForm:
if ( ( 0 != $userid ) && ( $this->mArticle->getUser() == $userid ) ) {...}

The response should be to then query the database for the most recent revision to this article made after
$this->edittime by anyone who is not $userid. If no such revision exists, then everything is fine, cancel
the conflict and continue at will. If such a revision is found then it should replace the contents of $this-

mArticle and the branch for merging / edit conflict resolution should be tried.

I believe this will solve the bug. I have no idea how easy it would be to implement.

Best wishes.

-DF

w:en:User:Dragons flight

rowan.collins wrote:

*** Bug 3059 has been marked as a duplicate of this bug. ***

andreengels wrote:

In Bug 3604, I submitted the same bug, with a hand-made example of a page that
goes wrong

rowan.collins wrote:

*** Bug 3604 has been marked as a duplicate of this bug. ***

mediawikibugs wrote:

(In reply to comment #28)

In other words, when I am editting, all my edits are made in reference to the

version I opened for editting

(call it version 1). Then while I am editting someone else makes some changes

and saves as version 2. Now

when I save the first time, it notices that someone else has made an edit and

tries to merge them. If this

succeeds, then we arrive at version 3A. Now, being dumb, I notice that I

misspelled "celebration", so I hit

the back button, quickly fix it and save again. This time the software

notices version 3A, sees that I also

made that edit and consequently, it cancels all edit conflicts. Since I used

the back button, my edit is

still based on version 1. So this time when it saves, the conflict with

version 2 is ignored. Hence,

whatever changes which were made in that version are dropped from the new

version 3B.

I can confirm this behavior. I was able to exactly duplicate this testcase on
the following:

• MediaWiki: 1.5.3
• PHP: 4.3.11 (apache)
• MySQL: 4.0.25-standard
• Linux 2.4.21-4.ELsmp

Restored from flood attack.

brian.klug wrote:

I can reproduce on MediaWiki 1.5.8.

I cannot reproduce on Wikipedia -- instead of overwriting changes, a conflict
screen shows up.

Has this bug been fixed?

andreengels wrote:

No, not been fixed. On 27 April, Ugur Basak Bot got this problem on [[en:White
House]].

rory096 wrote:

It works fine for me.
http://en.wikipedia.org/w/index.php?title=User%3ARory096%2Fsandbox&diff=55322755&oldid=55198547

http://en.wikipedia.org/w/index.php?title=User%3ARory096%2Fsandbox&diff=55323269&oldid=55322755

http://en.wikipedia.org/w/index.php?title=User%3ARory096%2Fsandbox&diff=55323301&oldid=55323269

And it didn't readd the "blah" in the first section. Also, I frequently get
edit conflicts with myself (though not there, because it's a different section).

andreengels wrote:

Rory: I don't know what you have tested, but I DO get the problem:

http://nl.wikipedia.org/w/index.php?title=Gebruiker:Andre_Engels/Test&diff=4965810&oldid=4804009
http://nl.wikipedia.org/w/index.php?title=Gebruiker:Andre_Engels/Test&diff=4965817&oldid=4965810
http://nl.wikipedia.org/w/index.php?title=Gebruiker:Andre_Engels/Test&diff=4965820&oldid=4965817

The third edit should have reverted only the second one (or raised some edit
conflict warning), but it actually did revert the first one as well.

Fixed in r42034