Last modified: 2013-03-06 10:09:59 UTC
Now, EditPage::internalAttemptSave() suppresses the conflict and does not merge changes for revisions created by the same user, i.e. if you click edit in two browsers tabs, then change something in 1st, click save, change something other in 2nd and also click save, your changes added in 1st tab will be lost. My opinion is that losing changes is incorrect :) I think the whole "if" block suppressing the conflict for same user should be removed from EditPage.php :) or at least made optional.
IIRC we originally added this for the following (verrrrrry common at least back in '02-03) case: * user hits 'edit', makes some changes * user hits 'save' and is redirected to the view page * user remembers he/she wants to add something else, hits 'back' to return to the edit page * edit page comes back in its previous state, with all the user's changes but with the edit time marker that indicates you're still working from the previous revision * user makes some more changes * user hits 'save' If anything that was changed in the first edit is changed further in the second, it would be unable to resolve the two edits with diff3, and kick out an edit conflict warning. By suppressing the edit conflict, we let the edit just go right through; since you started with the same text we can consider that you've "merged" it yourself, basically. Now it may have changed somewhat in the meantime, but if we are to change how this is handled to make other cases work, we still want to handle this common case cleanly.
Well, the changes of the first tab aren't lost. They are stored in the history, but missing in the last version. I oppose to producing edit conflicts for the edit-by-going-back process.
Hm. I didn't think of it. I sometimes do edit-by-going-back myself and sometimes really get a conflict in patched wikis; sometimes it's automerged. Really, this could be solved without breaking the edit-by-going-back if the edit form had some unique edit token, so that MW could determine if the save request was sent from the same form twice. I personally think an additional conflict ("false alarm") is not so bad, and an unwanted revert of changes ("target miss") is bad. For example: is there a browser that caches an opened edit form between restarts, but loses the modified content? I think Opera does so... If you click Save on such form, you'll have the page reverted even if changes were already saved and even if the edit form has a unique token. Of course, no changes are lost totally, but they can be "lost in history", i.e. you can miss that your changes were reverted.
> I sometimes do edit-by-going-back myself and sometimes really get a conflict in patched wikis; sometimes it's automerged. Things like ~~~~ can still produce conflict with yourself (you are conflicting in the datetime). > I personally think an additional conflict ("false alarm") is not so bad Adding a reply in a section edit, and then getting a diff of the full village pump is quite bad. > is there a browser that caches an opened edit form between restarts, but loses the modified content? It should either cache your modificarions or not cache anything. Can you test? Maybe we could help there by showing a notification bar of "ignored conflict with yourself". >Really, this could be solved without breaking the edit-by-going-back if the >edit form had some unique edit token, so that MW could determine if the save >request was sent from the same form twice. How long would you keep such whitelist of edits to not conflict with?
So, this appears to be a WONTFIX, but bug 34423 seems to (confusingly) prove that not all self-conflicts are being suppressed as intended.
Bug 26821 is a clean example of failure of the self-conflict suppression.
I.e. you also think that conflict suppression is bad? So why WONTFIX?
(In reply to comment #7) > I.e. you also think that conflict suppression is bad? No, it's good. It should always work but it sometimes doesn't. > So why WONTFIX? Because we should go in the opposite direction.
