Page MenuHomePhabricator

Make rollback use POST instead of GET (use AJAX in GUI)
Open, Stalled, HighPublic

Description

GET should be idempotent and it would be nice to tell read/write requests from the verb for active/warm DC logic.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Stryn added a subscriber: Stryn.May 26 2016, 8:37 PM

I'm also worried about current antivandalism actions no longer working as they did.

Agreed, as quite active user at antivandalism work, this is not nice that I have now to confirm the action. I'm used of opening (revert-)links in new tabs.

Krinkle added a comment.EditedMay 26 2016, 8:54 PM

this is not nice that I have now to confirm the action. I'm used of opening (revert-)links in new tabs.

Presumably that habit emerged because the rollback may take time to complete and you'd like to stay on the same page while continuing to check or rollback more edits. In fact, I have the same workflow.

A normal click now results in the AJAX rollback with notification coming in later. Thus providing the same experience as before (staying on the same page), without the need to open separate tabs.

If you open links in tabs manually via the context menu, then you'll get the confirmation page as such a regular link opening is not of type "POST" and wouldn't have security tokens in it.

@Stryn Do you open the links in a new tab manually, or do you use a shortcut? (shift-click, ctrl-click, middle-mouse-click, etc.). If the in-page AJAX handling is not triggered for your shortcut, we can add support for it. Let me know if that is the case (e.g. maybe it works on ctrl-click right now, but not middle-click).

We can also improve the way notifications are shown. Should they stay, or auto-hide like watch/unwatch does? What do you think about "mark as patrolled" links? Those have been going through AJAX the same way for some time now.

The web request for rollback has to be POST for good technical reasons. Either via a form, a confirmation screen, or (as done) via JavaScript.

I'm entirely open to suggestions for how to improve the experience of rollback interactions. I'm a frequent countervandalism user myself and want to make sure this is effective for everyone.

A normal click now results in the AJAX rollback with notification coming in later. Thus providing the same experience as before (staying on the same page), without the need to open separate tabs.

Not quite the same as before. If I understand correctly, you won't get a rollback diff now after the revert, which in many cases was useful to double-check that you reverted the right edit, or the revert was complete.

Could be the new design made optional? I think that this is so much slower then clasic rollback. For example I want to do massive rollback. I must click on each button and wait until completing instead of opening in new window. Or at least, please make this opt-out for each wiki. Thanks.

Base awarded a token.May 27 2016, 11:46 AM

Undo request is open: T136375

For example [if] I want to do massive rollback. I must click on each button and wait until completing instead of opening in new window. Or at least, please make this opt-out for each wiki. Thanks.

@Urbanecm Please note that this is not true. I'm a frequent rollbacker myself, and your reasons are exactly why it was made this way. There is no need to wait between rollbacks. They will work at the same time, just like background tabs.

But, because this change broke various automation tools, I'm reverting the software change and we'll improve it before over the next week week or two. Please continue at T136375.

Krinkle reopened this task as Open.May 27 2016, 8:03 PM

Implementation was reverted in 5391e328. Issues with it have been collected at T136375.

Teles added a subscriber: Teles.May 28 2016, 2:31 AM
RuyP added a subscriber: RuyP.May 28 2016, 3:25 AM

@Krinkle Ok. Thanks. But if I rollback some change without new page with result by mistake, I have smaller chance for notice this mistake.

Given the notes in T88044#1443652, I think this task would be fairly easy for a new developer, so I've marked it as such.

Not quite easy!

TheDJ added a subscriber: TheDJ.Jun 6 2016, 7:30 PM

Should we do some statistic and user-agent gathering on this before the next attempt, like has been done for the POST http -> https transition ?

Are the users who disable the display of a diff below the rollback success message more likely to be ok with the confirmation step upon GET?

Krinkle added a comment.EditedJun 7 2016, 4:49 PM

Are the users who disable the display of a diff below the rollback success message more likely to be ok with the confirmation step upon GET?

This question is slightly complicated because the confirmation step is an only supposed to be seen by users in browsers without supported JavaScript, and as fallback in case of an error in the AJAX code.

The previously used design (which I reverted) made two effective changes to the workflow of "click rollback link":

  • The "rollback success" message was rendered as in-page notification instead of a separate page load.
  • The message (being a small bubble) has no room for a diff. As such, the diff was made accessible via a link inside the bubble.

For users with the "no diff after rollback" preference enabled, the second change is indeed not observable as the AJAX logic did not consider this preference and always displays a link.

The diff after rollback is essential. A rollback link should be able to submit (POST) a form by itself.

ori removed Krinkle as the assignee of this task.Jul 11 2016, 6:53 PM
Krinkle moved this task from Doing to Blocked on the Availability board.Aug 18 2016, 8:19 PM

I will set up a meeting with designers and move this forward.

Gilles added a comment.Jan 4 2017, 5:05 PM

@Krinkle @Tnegrin has a meeting been scheduled yet?

yes -- today!

We had the meeting and have a good understanding of the issue. There are some technical issues regarding keeping the UX the same as the GET version so we're going to have to assess the tradeoffs around different implementations. We'll keep the ticket updated.

Gilles moved this task from Blocked to Radar on the Performance-Team board.Jan 5 2017, 9:58 PM
Halfak added a subscriber: Halfak.Jan 30 2017, 4:37 PM
Shawn added a subscriber: Shawn.May 3 2017, 2:35 PM
Krinkle changed the task status from Open to Stalled.May 26 2017, 5:09 PM

We'll keep the ticket updated.

Any updates?

Krinkle removed a subscriber: Krinkle.Sep 19 2017, 6:49 PM

I suggest modifying the contributions page as follows:

  • Remove the "change visibility" link and the "rollback" link.
  • Add an unlabelled bulk action checkbox at the start of each line.
  • At the end of the page, or floating in a margin, provide a bulk action form.
  • Provide a dropdown allowing the user to select "rollback" or "change visibility".
  • In JS mode, when "rollback" is selected initially or when the checkboxes are modified, do an API request to fetch a summary of the number of edits to be rolled back in each case. This replaces the edit count previously given in the rollback links.
  • Provide an edit summary box, allowing the edit summary of the rollback to be overridden. This would replace the gadget which currently does the same thing.
  • Clicking submit the submit button in rollback mode will perform the rollback operation.
  • If any non-current revisions were selected, these are ignored, the rest of the rollback batch goes ahead. The non-current revisions are listed as an error on the confirmation page.
  • In the minimum viable product, clicking the submit button navigates to a new multiplexed action contribsubmit, analogous to historysubmit.
  • As an extension to the MVP, if JS is available, the submit button could show feedback within the same page.
  • The contribsubmit rollback page shows all the diffs of the actions taken, replacing the output of the previous rollback action.
  • The contribsubmit "change visibility" page should show a bulk confirmation page very similar to the existing action=revisiondelete. That is, it requires a second click to take action.

The dropdown could have "rollback" selected by default. Since there is a single confirmation page for bulk rollbacks, it would be possible to provide a button to undo the bulk rollback, improving the feeling of safety and thus the justification for "rollback" as default. Rollback certainly makes sense as the default for users without access to other bulk actions.

On the other hand, if the bulk action interface is extended to include less destructive actions, like bulk undo with confirmation, then it may be confusing and dangerous to make "rollback" be the default.

The history page is simpler since there is at most one rollback link per page. A rollback button embedded in the current revision row would suffice, at least as a non-JS fallback.

JEumerus added a comment.EditedFeb 1 2018, 10:25 AM

Seems like such a construction would increase the time it takes for an edit to be rolled back, which is a problem for vandalism on highly visible pages (I've seen pages on enwiki with 100,000 or so views per day) and for wikis with lots of readers and lots of rollback actions (even if the added delay only increases the number of readers that see a vandalized version by 0.01 readers/rollback, this stacks up on a wiki with 1000 rollbacks per day to 10 readers) since it increases the visibility of vandalism. No opinion on what the cost/benefit ratio is at the end.

Charlie_WMDE added a subscriber: Charlie_WMDE.EditedFeb 9 2018, 9:48 AM

Hello everyone,

on the German technical wishlist survey of 2017 wish nr.7 was to add a confirmation prompt for the rollback action because it seems to be a common situation that user accidentally trigger the action when trying to thank someone for example, and then having to revert the rollback and apologize to the the editor who's edit got reverted. Currently it seems like we would add a default confirmation prompt (similar to the confirmation when thanking) for all users which can be switched off in the preferences but the research is still ongoing.

It seems to me that this discussion might change things in the way we should approach this wish. Unfortunately it's hard for me to tell what the consequences of using POST instead of GET would mean for the work flow and the UI. Would it be possible to update the task description so a non-tech person can understand the implications as well?

Thanks!

@Charlie_WMDE These changes should not affect that. Just about the only effect this will have on the interface is that the rollback link can no longer be a plain HTML link – either it would have to be turned into a tiny form with a button, or it would have to use JavaScript to perform the changes, which is what you're planning to do anyway :)