Last modified: 2010-05-15 15:33: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 1181 - Section edit bug where entire article is overwritten on save
Section edit bug where entire article is overwritten on save
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.4.x
All All
: Normal major with 4 votes (vote)
: ---
Assigned To: Aaron Schulz
http://en.wikipedia.org/wiki/EMD_E-unit
:
: 325 1288 1806 3919 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-23 21:06 UTC by Matthew Brown
Modified: 2010-05-15 15:33 UTC (History)
6 users (show)

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


Attachments

Description Matthew Brown 2004-12-23 21:06:08 UTC
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.
Comment 1 Dieter Menne 2005-01-10 16:23:35 UTC
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.
Comment 2 Tomer Chachamu 2005-04-01 22:07:05 UTC
Works for me.
Comment 3 Tomer Chachamu 2005-04-01 22:08:02 UTC
*** Bug 1288 has been marked as a duplicate of this bug. ***
Comment 4 Zigger 2005-04-03 07:04:40 UTC
*** Bug 1806 has been marked as a duplicate of this bug. ***
Comment 5 R. S. Shaw 2005-04-26 20:10:48 UTC
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
Comment 6 Zigger 2005-06-22 19:08:28 UTC
*** Bug 325 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2005-08-07 00:50:12 UTC
*** Bug 1806 has been marked as a duplicate of this bug. ***
Comment 8 Robert Rohde 2005-09-03 16:46:49 UTC
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
Comment 9 Brion Vibber 2005-09-04 05:17:28 UTC
A save will fail in that case because the hidden fields at the end are 
missing.
Comment 10 Robert Rohde 2005-09-04 07:40:30 UTC
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.
3) 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
Comment 11 Brion Vibber 2005-09-04 22:22:15 UTC
So, you've got a broken page with a bunch of missing text, and you 
decide to save it?
Comment 12 Robert Rohde 2005-09-05 00:49:57 UTC
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.
Comment 13 Brion Vibber 2005-09-05 05:01:11 UTC
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?
Comment 14 peter green 2005-09-05 23:20:35 UTC
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. 
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-06-26 03:03:58 UTC
*** Bug 3919 has been marked as a duplicate of this bug. ***
Comment 16 Strainu 2008-06-16 09:02:10 UTC
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.
Comment 17 Aaron Schulz 2008-10-13 15:36:54 UTC
(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
Comment 18 Aaron Schulz 2008-10-13 15:41:09 UTC
Hidden fields checked in r42037.

The edit conflict "skip-if-last-editor" bug was fixed in r42034.
Comment 19 Brion Vibber 2008-10-25 20:09:39 UTC
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.
Comment 20 MER-C 2008-12-10 11:02:10 UTC
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.
Comment 21 Aaron Schulz 2009-01-13 15:01:22 UTC
(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?
Comment 22 Aaron Schulz 2009-01-16 19:57:25 UTC
Fix in r45809

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


Navigation
Links