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?

In T88044#2358717, @Nemo_bis wrote:

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.

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

@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.

In T88044#2919528, @Tnegrin wrote:

We'll keep the ticket updated.

Any updates?

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.

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.

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 :)

Un-parenting from T92357 as changing rollback is not a blocker for multi-DC. Its route will be excempted and treated like POST (see T91820).

Personally, I think it helps with countervandalism that it uses a get request; I can click to open the link in a new tab to trigger the rollback, and while that loads go warn the user (for example) - I would object to such a change

This is likely the cause of a user making multiple rollbacks at once without even interacting with the page nor receiving any confirmation that they made these rollbacks. Making the rollback a POST request would have stopped this from what I've been able to tell. Discussed on the CU mailing list. Adding Security-Team because of this. If not within the scope of the security team, then remove.

Hi @Dreamy_Jazz - We appreciate the mention, but unfortunately we do not plan to work on this issue anytime soon.