Last modified: 2013-03-06 10:09:59 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 28720 - Do not suppress conflicts for same user edits
Do not suppress conflicts for same user edits
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-27 15:56 UTC by Vitaliy Filippov
Modified: 2013-03-06 10:09 UTC (History)
2 users (show)

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


Attachments

Description Vitaliy Filippov 2011-04-27 15:56:25 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.
Comment 1 Brion Vibber 2011-04-27 22:00:50 UTC
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.
Comment 2 Platonides 2011-04-27 22:44:42 UTC
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.
Comment 3 Vitaliy Filippov 2011-05-03 17:17:41 UTC
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.
Comment 4 Platonides 2011-05-03 18:17:06 UTC
> 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?
Comment 5 Nemo 2013-03-06 08:13:52 UTC
So, this appears to be a WONTFIX, but bug 34423 seems to (confusingly) prove that not all self-conflicts are being suppressed as intended.
Comment 6 Nemo 2013-03-06 08:30:29 UTC
Bug 26821 is a clean example of failure of the self-conflict suppression.
Comment 7 Vitaliy Filippov 2013-03-06 10:05:11 UTC
I.e. you also think that conflict suppression is bad?

So why WONTFIX?
Comment 8 Nemo 2013-03-06 10:09:59 UTC
(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.

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


Navigation
Links