Last modified: 2013-12-29 08:25:21 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 1893 - Show a message after rollback has completed
Show a message after rollback has completed
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-15 02:29 UTC by SJ
Modified: 2013-12-29 08:25 UTC (History)
4 users (show)

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


Attachments

Description SJ 2005-04-15 02:29:46 UTC
When viewing a user's edit history, a "rollback" link is offered to admins next
to each "(top)" edit.  Accidentally clicking on such a link automatically undoes
not only the last edit by that user, but a series of them, if the user has made
many edits to a single page.

There is no confirmation or even verification that this has occurred; the admin
is simply taken to the (now rolled-back) page.  So if you don't know what the
page looked like before, and you click "rollback" by accident, it looks as
though you clicked on the page title by accident (which is right next to it).  

An extreme side-effect of this can occur on pages that are maintained by a
single person only, or that are private projects of a single person; for
instance, one's User Page, or a Wikinews article, or a WikiProject that one is
getting up to speed with little help from others. 

Two suggested fixes:  
 1) Add a red-text "this article has been rolled back to the revision on <date>
by [[User]] 
 2) Add a confirmation page : "This page will be reverted to the revision on
<date> by [[User]].  Is this what you want to do?"

The confirmation page should *definitely* be in place on sites like Wikipedia
when reverting edits of another active user; perhaps it could be done when
reverting the work of any non-IP  Or any non-newbie.
Comment 1 JeLuF 2005-04-16 04:22:51 UTC
The rollback button is for reverting vandalism and similar. It's a shortcut to
speed this task up. Thus I'd prefer solution #1. The rollback can be easily
reverted as soon as the admin notices his mistake.
Comment 2 SJ 2005-05-13 05:01:35 UTC
I agree that #1 is the right thing for large sites like Wikipedia.  

There could be a configuration option to add a confirmation window... for
smaller sites, with fewer distinct editors, an uncaught rollback would on
average be quite significant -- that is, the average number of consecutive edits
by the same editor on a page would be large.
Comment 3 Rob Church 2005-10-30 15:21:00 UTC
Sysops can roll themselves back, so I don't see what the big deal is.
Comment 4 SJ 2005-11-12 13:30:25 UTC
The big deal is that "no confirmation" means you don't realize you've 
done it, so you *can't* roll yourself back.
Comment 5 Rob Church 2005-11-12 15:25:00 UTC
You shouldn't be using rollback without taking a few seconds to check before and
after.
Comment 6 SJ 2006-11-08 07:42:14 UTC
Please, for the love of all that is good and honorable, spend a minute considering this bug report.  I am sorry that I wasn't clear before: 

a) It is possible to misclick or click hastily while viewing a user's contributions page.  
b) This misclick can rollback an edit without the user meaning to
c) The result of a rollback is to take you to the page now-rolled-back WITH NO NOTICE THAT A ROLLBACK HAS TAKEN PLACE.  Note that this is the same behavior expected from following a link to the current revision of the page.
d) This would seem to be the normal result of having clicked on the much larger link to the page itself from the user's contributions history.  
e) If the page title and username wrap over more than one line, a rollback link can appear directly beneath the actual link to the latest revision of a page; a misclick can involve being off by only a few pixels.


Compounding this problem: 
f) If the page has a long title, or if the user has contributed many times in a row to the same page, there may 10x or 20x more space on the contributions page that links to a revision of the page without rollback, than space that performs a rollback; a misclick can seem statistically unlikely to the user. 
Comment 7 Brion Vibber 2006-11-08 16:46:10 UTC
#2 is a definite no-no; the purpose of the rollback ability is to minimize the pain of making a lot of reversions in big vandalism 
cases.

#1 would be good.
Comment 8 SJ 2008-01-30 05:40:41 UTC
Revisiting this bug, which still persists.  I've now run into 'dangerous' situations because of it numerous times, though after being bitten the first time, leading to filing this bug, my spider sense always kicks in in time.

I browse someone's contribution history.  This includes pages with long edit summaries (at least long enough to traverse a full line on the history page at my screen resolution).  I move to see a specific page that someone was editing (the first time that page shows up in the history is the one that piques my interest; it is also the one likely to have (top) [rollback] at the end of the edit summary), and the "[rollback]" link is directly below part of the timestamp.   

Or I want to "diff" their last edit, and the "[rollback]" link is directly below the diff link.

In the first case, following the rollback link looks just like following the timestamp would - you see the 'latest' version of the page (after you have rolled back, if you clicked [rollback] by mistake) with no extra highlighting or notification text.

In the second case, you see the current revision, rather than a diff.  However, the easiest explanation is that you missed the 'diff' link and hit the timestamp, not that you hit a [rollback] link.  so you back up to the previous page and try the 'diff' link again, and see the expected diff (unless you are very sharp you won't notice that that is no longer a diff from the latest revision, and that there is a new more-recent diff [your rollback]).

So, one very easy solution this suggests : 
  #3  make the placement of "(top) [rollback]" more consistent across pages : after the page title, BEFORE the edit sumamry.

  #1 above is still the best possible soltion, perhaps in addition to #3.  

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


Navigation
Links