Last modified: 2010-05-15 15:33:44 UTC
A user on german wikinews came across the following behaviour twice: he edited the page, saved it, clicked in his browser on "stop loading" and edited the page another time. On this second edit previous edits get deleted. The first time it deleted the two previous comments from other users: http://de.wikinews.org/w/index.php?title=Wikinews:Pressestammtisch&diff=8121&oldid=8117 the second time it just deleted one previous edit: http://de.wikinews.org/w/index.php?title=Wikinews:Pressestammtisch&diff=8477&oldid=8476 description in german: http://de.wikinews.org/wiki/Wikinews:Pressestammtisch#Der_.22Zensurbug.22_ist_reproduzierbar
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)
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.
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.
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: 1) 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 2) I opened "Sektion 1" for editing (section edit) in a new Window (window 1) 3) I opened "Sektion 2" for editing (section edit) in a second new window (window 2) 4) 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 5) 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.
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...
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: 1) Again two sections: http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=4394445 2) 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) 3) 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) 4) 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 5) 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 6) 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)...
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.
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/20050511 Firefox/1.0.4" -- mdonn@harbornet.com
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.
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.
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.
[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.
*** Bug 1601 has been marked as a duplicate of this bug. ***
(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.
(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.
(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.
(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.
(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.
(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.
(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.
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.)
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...
s/disappear/appear/
(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. ~~~~
(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.
*** 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
*** Bug 3059 has been marked as a duplicate of this bug. ***
In Bug 3604, I submitted the same bug, with a hand-made example of a page that goes wrong
*** Bug 3604 has been marked as a duplicate of this bug. ***
(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.
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?
No, not been fixed. On 27 April, Ugur Basak Bot got this problem on [[en:White House]].
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).
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