Page MenuHomePhabricator

Section editing may revert previous edits
Closed, DeclinedPublic

Description

Author: qleah

Description:
Editing a section may frequently undo changes made to other sections. This
affects sections which could never have been modified; i.e. editing section 10
may revert changes in section 7.


Version: unspecified
Severity: major
URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Cleanup&diff=10592514&oldid=10592207

Details

Reference
bz1601
ReferenceSource BranchDest BranchAuthorTitle
repos/abstract-wiki/wikifunctions/function-orchestrator!149apine-dont-resolve-languagemainapineDo not resolve or validate languages on Z17s.
repos/commtech/autosuggest-sitelink!45open-dialog-immediately-and-in-a-loading-statemainthierryw23feat: allow the user to link a wikidata item to an article
repos/commtech/autosuggest-sitelink!44rm-colormainsamwilsonKeep link greyed out during loading
repos/commtech/autosuggest-sitelink!42Move-the-AutosuggestSitelink-under--What-links-here--in-the-tools-menumainthierryw23Move the AutosuggestSitelink to be under 'What links here' in the tools menu
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 8:14 PM
bzimport set Reference to bz1601.
bzimport added a subscriber: Unknown Object (MLST).

mozilla-bugzilla wrote:

Whenever I've used the section editing feature and somebody else has made a
change, I've had an edit conflict. Could you explain how to reproduce this better?

qleah wrote:

I encountered two edit conflicts in a series of edits, but that does not account
for all of the reversions. See the history for [[Wikipedia:Cleanup]] to see
which sections were edited and which lines removed; try it for yourself if you like.

alphasigmax wrote:

(In reply to comment #1)

Whenever I've used the section editing feature and somebody else has made a
change, I've had an edit conflict. Could you explain how to reproduce this better?

In a tabbed browser, edit two sections on the same page at once. The second edit
will revert the first one.

rowan.collins wrote:

(In reply to comment #3)

In a tabbed browser, edit two sections on the same page at once. The second edit
will revert the first one.

The code is special-cased to ignore any edit conflict with yourself, to avoid
problems when someone clicks "save" twice. This may or may not be the cause of
bug 275, which is a pain in various parts of the anatomy, but it *is* a
deliberate feature.

If you had multiple windows or tabs open, editting different sections, the last
one you clicked "save" on would indeed overwrite the others. The fact that this
affects text outside the editted section is unintuitive, but presumably a result
of the fact that the section has to be added back into the rest of the text
before the save goes through (otherwise, you'd end up with nothing but the
editted section).

rowan.collins wrote:

*** This bug has been marked as a duplicate of 1150 ***

andreengels wrote:

This is not a duplicate of 1150, although it is related, and the same problem is
discussed there as well. It is quite likely that when there is a solution of bug
1150, this one still is broken. I therefore re-open this bug.

andreengels wrote:

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

wegge wrote:

Running away in horror from this bug, and hopefully not screwing the CC list
totally up

sy1234 wrote:

Steps to reproduce:

  • Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
  • Create a new page and edit it
  • Make two sections: = Section One = = Section Two =
  • Save the page
  • control-click the 'edit' link for both sections, opening up two new tabs
  • visit the first tab, add "foo", and save
  • visit the second tab, add "bar", and save

Current Result: An edit conflict with the earlier "foo" edit.

Earlier Result: The page is saved, and only "bar" is seen. This was probably MediaWiki 1.4 or 1.5.

Expected Result: No edit conflict, the second section is saved, and both sections remain, with the new "foo" and "bar" text.

While the original bug is no longer there, the expected result is not given.

Following the given steps in comment #10 I receive the expected result: page is saved with automatic conflict resolution.

Note that if your server's system was unable to locate GNU diff3, you will get an edit conflict display because the infrastructure for the merge isn't present.

It may also be possible to get a conflict trigger if the page is so tiny that it got confused by completely adjacent lines -- for instance if you don't put line spacing between the raw section headers. Then diff3 isn't able to distinguish the sections for sure, and throws a conflict rather than guess wrong.

This is correct, if conservative behavior, and doesn't seem to be an issue in actual usage (where you get nice spacing).