Page MenuHomePhabricator

Section edit bug where entire article is overwritten on save
Closed, ResolvedPublic

Description

Author: morven

Description:
I did a section edit on [[EMD E-unit]] on en-Wikipedia, on the section 'Trucks'.
When I clicked on save, the entire article was replaced by just the section I
had edited. I have reverted the change, but it's in the history.


Version: 1.4.x
Severity: major
URL: http://en.wikipedia.org/wiki/EMD_E-unit

Details

Reference
bz1181

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:07 PM
bzimport set Reference to bz1181.

dieter.menne wrote:

I can confirm this bug on the local installation.
Only occurs when "open preview on first edit" is on.
As a temporary workaround, disable this option in the php-code.

the.r3m0t wrote:

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

zigger wrote:

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

shaww wrote:

I seemed to have also had a case of this. I had clicked the edit link on the
"Strong monochrome" section of the page. I had previewed my change. After I
saved it. I noticed the section had replaced the entire page. (I reverted it.)
I hadn't been using "open preview on first edit" option, but had previewed the
change. The history entry for the edit is at
http://en.wikipedia.org/w/index.php?title=Wikipedia:Template_standardisation&diff=12810897&oldid=12810669

zigger wrote:

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

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

We have just had a couple more reports of this on Wikipedia EN.

I believe this bug is caused as follows: Someone 1) Uses edit section. 2)
Makes changes to the article and uses show preview. 3) The preview looks
alright, but the page is slow to load. 4) They hit save page before the page is
fully loaded.

As the section editting token "wpSection" is one of the very last things to load
on the edit page (well after the save button), I believe that during slow page
loads, people are occasionally managing to save the page before the section
token has been included in the form. By default this leads the server to
interpret the data as an attempt to save the entire page. Bugginess ensues.

Solution: Move all the hidden fields on the edit form to somewhere before the
save button is rendered.

-DF

A save will fail in that case because the hidden fields at the end are
missing.

Brion,

Your expectations are reasonable but not entirely correct.

I've done some testing by saving local copies of edit pages and removing the
hidden fields.

The following events can occur.

  1. Edit a section.
  2. Lose the hidden fields. Presumably in practice this could occur by hitting

save or preview before the page is completely loaded, but I just removed them
from a local copy of the page.

  1. If the hidden fields are "lost" in this way the next load will be a preview

screen and the hidden values are set to "" for wpStarttime, wpSection, and
wpEdittime. Remarkably the lost EditToken was actually restored to the same
value it had before I removed it (is this stored in the session?)

So now I have a preview screen with a valid edit token but no knowledge of what
version or section I started editting.

If I save again, the software will either a) give an edit conflict, if someone
other than myself was the last edit, b) save the edit and replace the entire
page with the contents of the section I was editting.

The b scenario only occurs if I was also the last person to save the page. I
assume this is an example of edit conflicts with self being cancelled, so that
even though the software doesn't know what version I started editting from, it
doesn't care and saves anyway.

Regardless, it really shouldn't be possible to reach an edit screen where the
section and version information have been thrown away. I would again suggest
that the hidden fields should be part of the edit page HTML before
save/preiew/etc buttons are loaded.

-DF

So, you've got a broken page with a bunch of missing text, and you
decide to save it?

It is clear from this example,
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%
29#Editing_a_page_and_the_Insert_Box_causing_saving_errors

that the guy was hitting save before the page had completed loading, and
hence submitting an incomplete form.

In that case the edit would fail, and show a preview. He would then have
to continue with a second page save. Is this what he's doing?

plugwash wrote:

remember there have been periods when wikipedia has repeatedly gone to preview
when trying to save so many of us just hit the save button if we see an unwanted
preview. we aren't that likely to notice if the word section in brackets
dissapears from the preview page.

ayg wrote:

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

In my case, the problem occurred because I had closed the browser (Firefox 2) after I hit preview, the re-opened it. The page had obviously lost some information. Perhaps it would help if you put the section that is currently being edited as a GET field? Don't know if it would work for the other scenarios that lead to this bug, though.

(In reply to comment #8)

We have just had a couple more reports of this on Wikipedia EN.

I believe this bug is caused as follows: Someone 1) Uses edit section. 2)
Makes changes to the article and uses show preview. 3) The preview looks
alright, but the page is slow to load. 4) They hit save page before the page is
fully loaded.

As the section editting token "wpSection" is one of the very last things to load
on the edit page (well after the save button), I believe that during slow page
loads, people are occasionally managing to save the page before the section
token has been included in the form. By default this leads the server to
interpret the data as an attempt to save the entire page. Bugginess ensues.

Solution: Move all the hidden fields on the edit form to somewhere before the
save button is rendered.

-DF

wpSection now loads before the textarea

Hidden fields checked in r42037.

The edit conflict "skip-if-last-editor" bug was fixed in r42034.

I've reverted r42037 in r42569.

I don't think this check has any real benefit, since in the form the fields appear before the text box there's basically no way to submit the form without them. However the more stringent checks are causing disruption to bot edit tools, which annoys people, so I'm backing it out for the time being.

The moved fields should already have fixed the base issue, so leaving bug resolved.

Reopening - seems to still be a problem with the live version (r43634) see http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AFeatured_picture_candidates&diff=256999377&oldid=256996105 . What I remember doing was waiting a long time, show preview, waited another long time then saved.

(In reply to comment #20)

Reopening - seems to still be a problem with the live version (r43634) see
http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AFeatured_picture_candidates&diff=256999377&oldid=256996105
. What I remember doing was waiting a long time, show preview, waited another
long time then saved.

What were you trying to do?

epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:21 AM