At the very least, couldn't there be an option in Special:Preferences to revert this change?

In T136375#2333909, @K6ka wrote:

At the very least, couldn't there be an option in Special:Preferences to revert this change?

I don't really think this is really what the main problem is, namely, that this change (which is about the format of the HTTP packets and how the server responds) is breaking tools. In order to unbreak the tools on a the timescale we need (i.e. soon, we need these anti-vandalism tools) there needs to be at least a temporary rollback of this software change.

This is also preventing cswiki script https://cs.wikipedia.org/wiki/MediaWiki:Gadget-SafeRollback.js to work. This scripts should ask user before rollback to prevent unwanted changes. Please fix it ASAP.

+does anybody knows when this will be fixed?

I've gathered the following issues:

• Make sure the "summary" parameter works in the AJAX handling. (It already works in the API and it works in the confirmation page, but the in-page AJAX method doesn't look at the summary override).
• Don't auto-hide (or at least make the duration longer by default). We already don't auto-hide errors, but "Rollback success" notifications auto-hide after 5 seconds. This is the same as we've always done for watch/unwatch and for mark-as-patrolled.
• Bring back the token parameter in the GET fallback url. This way manually opening in a new tab will still work. We also do this with mark-as-patrolled. When we add this fallback, it should be considered deprecated (just as it is for mask-as-patrolled), and it will be removed in the future. But until we're sure all the main tools have migrated and we've uncovered any other issues, we should keep this functional.

Also:

• When using it on the history page, the history page is out of data after the revert is complete since there is now an extra edit in the history. Previously, by navigating to a different page (or opening a new tab), it being outdated feels more natural. Now one would need to manually refresh the page to see the edit. The script shouldn't do a refresh since users may want to revert multiple edits.
• A revert may not always work as expected. Previously, the diff was shown by default below page that said the rollback was successful. This diff tends to cover enough context that no further review is needed. Now, however, users get a small notification bubble with a link to the diff (which requires an additional click to open in a new tab to review). This makes reverting multiple edits tedious (and hard, since the bubbles disappear after a while).

I suggest we'll work on this next week. But for now let's rollback the rollback.

We need to think about how we want to implement this better. While the implementation was in line with our conventions and consistent with ajax interfaces for other page actions - there are things unique to rollback (reviewing the diff afterward, resulting in an edit, history page chaning etc.) that warrant a more elaborate interface. The interface we've used thus far for ajax patrol and ajax watch does not suffice.

From https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Rollback_function_has_been_changed

I can at least confirm the option to leave a custom edit summary with a rollback as described at Wikipedia:Rollback#Additional_tools still works. —k6ka 🍁 (Talk · Contributions) 02:35, 27 May 2016 (UTC)

https://en.wikipedia.org/wiki/Wikipedia:Rollback#Additional_tools
https://en.wikipedia.org/wiki/Wikipedia:Cleaning_up_vandalism/Tools#Rollback_tools
https://en.wikipedia.org/wiki/User:Mr.Z-man/rollbackSummary.js

The summary parameter is not used in MediaWiki core interfaces by default. But when adding it to the rollback link manually (via JavaScript) it does indeed still work when opening in a new tab (with the confirmation form). However the AJAX handling doesn't look at the "summary" parameter. ApiRollback supports "summary" fine. And the RollbackAction class supports it as well. It's just the AJAX handling. Thanks!

In T136375#2332835, @TTO wrote:

I don't think a revert is needed. [..] stop it from auto-hiding

Change 291249 had a related patch set uploaded (by Krinkle):
Revert "RollbackAction: Implement AJAX interface and require POST"

https://gerrit.wikimedia.org/r/291249

In T33270#2333124, @IKhitron wrote:

Hello. I was very surprised to see this change. I can't understand why anyone can think it's a good idea. Rollback and patrolling are not the same. Rollback works on more than one version and sometimes you revert more revisions than intented. Page diff showed this and the problem was fixed. Now you can make more changes that you wanted without even know. Actually, this change makes every patroller to be a potential unintented vandal with rollback superpower. Could you remove this change today, please? Thank you.

In T33270#2333393, @HeWikipedianMr.W wrote:

Hi,

I disagree with IKhitron. Till today you were passed to a page that just notified if the rollback worked or failed. You wren't shown the actual changes anyhow. So the only diff is that now you're notified this msg without being transferred to another page.

Please do NOT remove this change since it's very useful!

In T33270#2333445, @IKhitron wrote:

Hi Mr W. I already saw that you loved it. I have no idea why don't you see the diff. Maybe there is a bug in you account, or some script that changes the behaviour. But you are completely wrong. If you love this feature add it to your account as gadget, don't destroy wikipedia just because it's better to you personally.

In T33270#2333591, @Brian_He wrote:

I agree with IKhitron. I think that it is ok to use this method of rollback *by choice*, and let other users to choose differently.
You can make it even default if you want, but don't force my tools to work as you like.

In T33270#2334070, @He7d3r wrote:

@HeWikipedianMr.W: maybe you enabled the preference "Don't show diff after performing a rollback"?

In T33270#2334159, @IKhitron wrote:

Thanks, @Brian_He. I'm not so sure that default is a good idea, because what should we do if some patroller will not use it by default and will erase some article? Fire him? It's not serious.

In T136375#2332683, @Danny_B wrote:

Same issue like objected T135170: Require POST in ?action=purge?

It's quite different. action=purge is not output by MediaWiki by default. And its primarily accessed over URL (either by hand-written urls, template links, gadgets, and Semantic extensions).

On the other hand: Watch, patrol, and rollback are core parts of the MediaWiki interface. As such, MediaWiki has control to attach JavaScript handlers to these links by default and effectively cover 99% of their use (e.g. it's rare for someone to see a confirmation page when adding a page to their watchlist , even though action=watch technically has a confirmation page).

error also happens when I open diff links from irc.wikimedia.org Recent changes channels. Reverting from such diff also invokes confirmation button

Change 291293 had a related patch set uploaded (by Krinkle):
Revert "RollbackAction: Implement AJAX interface and require POST"

https://gerrit.wikimedia.org/r/291293

Change 291293 merged by jenkins-bot:
Revert "RollbackAction: Implement AJAX interface and require POST"

https://gerrit.wikimedia.org/r/291293

@Krinkle - thank you for the reversion - do you know the timeframe for when this will update production?

In T136375#2334903, @Xaosflux wrote:

@Krinkle - thank you for the reversion - do you know the timeframe for when this will update production?

A few hours at most.

Change 291249 merged by jenkins-bot:
Revert "RollbackAction: Implement AJAX interface and require POST"

https://gerrit.wikimedia.org/r/291249

This was also affecting my ConfirmRollback script. If you have the script installed and click on a rollback link on a page that you have set to "confirm", then the script will pop up a dialog saying "Revert n edits by SomeUser?" After the change, the rollback would occur directly after the initial click on the rollback link, regardless of the dialog.

@Krinkle - I noticed your comment "Removed spurious "return true;" from other method that resulted in a "1" being printed at the end of the page." - well this appears to have been promoted to the release, that "1" is showing - reported on enwiki and simple en

In T136375#2335622, @MrStradivarius wrote:

This was also affecting my ConfirmRollback script.

Also, I haven't tested it, but I would assume the same issue occurs for enwiki's default gadget confirmationRollback-mobile.

Change 291376 had a related patch set uploaded (by Legoktm):
RollbackAction: Don't return true, causes '1' to be output

https://gerrit.wikimedia.org/r/291376

Change 291377 had a related patch set uploaded (by Legoktm):
RollbackAction: Don't return true, causes '1' to be output

https://gerrit.wikimedia.org/r/291377

Change 291377 merged by jenkins-bot:
RollbackAction: Don't return true, causes '1' to be output

https://gerrit.wikimedia.org/r/291377

relevant task: T136422: Remove (or fix) preference to "Don't show diff after performing a rollback"

This change also appears to have broken PILT - see User:Philip Trueman/PILT - and it is still broken. PILT is based on AVT but uses AJAX for rollback, and has done for years. I would appreciate a pointer to the documentation for how I need to change the code to get it working again.

Change 291376 merged by jenkins-bot:
RollbackAction: Don't return true, causes '1' to be output

https://gerrit.wikimedia.org/r/291376

@Aklapper Returning them, since it's an issue which requires communication between WMF and community and devs.

Have members of such teams to decide whether to remove them if they will want to, thanks.

In T136375#2337826, @Danny_B wrote:

@Aklapper Returning them, since it's an issue which requires communication between WMF and community and devs.

Apart from the already existing User-notice tag (for weekly Tech News), the scope of Developer-Advocacy and Community-Relations-Support does not generally cover "communication between WMF and community and devs" as this task is about a regression bug and not about product development.

Have members of such teams to decide whether to remove them if they will want to, thanks.

I'm such a team member.

In T136375#2337861, @Aklapper wrote:

In T136375#2337826, @Danny_B wrote:

@Aklapper Returning them, since it's an issue which requires communication between WMF and community and devs.

Apart from the already existing User-notice tag (for weekly Tech News), the scope of Developer-Advocacy and Community-Relations-Support does not generally cover "communication between WMF and community and devs" as this task is about a regression bug and not about product development.

"We facilitate communications from and to the WMF Product department."
This task is about how WMF devs broke something and community is unsatisfied with that...

Have members of such teams to decide whether to remove them if they will want to, thanks.

I'm such a team member.

OK, new structure (again :-/). Valid point then... ;-)

[off-topic]

In T136375#2337864, @Danny_B wrote:

"We facilitate communications from and to the WMF Product department."
This task is about how WMF devs broke something and community is unsatisfied with that...

@Danny_B: The quote says Product department, which was and is not involved in this task.
(Please bring up potential followup discussion in a better place, as "What does team X do" is unrelated to this task. Thanks!)

Change 291761 had a related patch set uploaded (by Krinkle):
Fix rvtoken=rollback in ApiQueryRevisions

https://gerrit.wikimedia.org/r/291761

In T136375#2335925, @Philip_Trueman wrote:

This change also appears to have broken PILT - see User:Philip Trueman/PILT - and it is still broken. PILT is based on AVT but uses AJAX for rollback, and has done for years. I would appreciate a pointer to the documentation for how I need to change the code to get it working again.

Thanks. Restored in https://gerrit.wikimedia.org/r/291761. Will be deployed later today.

@Philip_Trueman: PITT/recent2.js uses query prop=revisions&rvtoken=rollback. This triggers the warning "The rvtoken parameter has been deprecated." since it was deprecated (generated docs, mediawiki docs) in 2014 (MediaWiki 1.24). This will continue to work for now, but to avoid breakage or hasty migration in the future, I'd recommend migrating to using the central token module (query meta=tokens&type=.., generated docs, mediawiki docs).

Change 291768 had a related patch set uploaded (by Krinkle):
Fix rvtoken=rollback in ApiQueryRevisions

https://gerrit.wikimedia.org/r/291768

Change 291761 merged by jenkins-bot:
Fix rvtoken=rollback in ApiQueryRevisions

https://gerrit.wikimedia.org/r/291761

Change 291768 merged by jenkins-bot:
Fix rvtoken=rollback in ApiQueryRevisions

https://gerrit.wikimedia.org/r/291768

Mentioned in SAL [2016-05-30T17:27:08Z] <krinkle@tin> Synchronized php-1.28.0-wmf.3/includes/api/ApiQueryRevisions.php: T136375 (duration: 00m 52s)