Different error:

In T426155#12009385, @TheDJ wrote:

Last error was from June 1st in 1.47.0-wmf.4

wmf4 is kind of curious, considering the changed landed in wmf3 branch.

Is this error still occurring?

In T428670#12003210, @Bugreporter2 wrote:

Why does it need to be able to handle raw HTML?

Seems to be fixed, thanks @Esanders!

@lihaohong can this be closed?

I'm fine with that as well, I'll update my patch.

That change was deployed 11 months ago though, and I've only noticed the bug very recently (in the last two weeks). It's also possible that I missed it before though, did anybody else ever notice this bug?

Removing good first task as this is clearly not uncontroversial.

First, as the response message is an error report, it should be wrapped in a ⚠️ yellow warning similar to the redirect errors:

In T426787#11955997, @Catrope wrote:

[...] I don't think it would be feasible to require it only for raw HTML messages, because MW doesn't really track those as such.

The same will have to be done for ApiDiscussionToolsEdit, which calls action=visualeditoredit internally.

(tagging VisualEditor as this is related to VE, and Product Safety and Integrity as the config code was added in T423252: Enable VisualEditor hCaptcha on testwiki)

I think the captcha issue was actually caused by https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/66a3710620a8693b7c3666e0584a7c7d042e75a5/wmf-config/CommonSettings.php#2226 (AFAICT the code controls whether hCaptcha or FancyCaptcha is used, and the task description of T426751 also says "Sometimes I also see an hCaptcha challenge that I have to complete before I see the FancyCaptcha challenge."). The action parameter will be overwritten in the DerivativeRequest and is therefore no longer visualeditoredit (what the config code checks for) but edit. To fix this, we would need some other way to detect whether the current edit is a VE edit...

https://gerrit.wikimedia.org/r/c/labs/codesearch/+/1267343 will allow implementing this option.

I didn't have the time yet to submit a patch for this task, but I probably will eventually. Not claiming for now in case somebody else wants to

In T426787#11939703, @Lucas_Werkmeister_WMDE wrote:

(I don't have editinterface on any WMF wiki, so I can't verify whether that's actually the case or if there is some other code somewhere that fixes this)

@LucasWerkmeister is an interface admin on Commons and can confirm that editing MediaWiki:Mobile-frontend-editor-editing-page, unlike editing MediaWiki:Gadget-ACDC.js, does not prompt for reconfirmation. (That said, they haven’t tried actually making an edit, so it’s still possible that there’s a reauthentication in the submit flow – though that seems unlikely.)

This fix should've been deployed through the train last week, are there still any errors?

Not actively working on this right now because using edit constraints in more places would make the ongoing EditPage/PageEdit refactoring more complicated. Removed patch-welcome for the same reason. I will pick this task up again at some point if no one else does until then.

The patch I uploaded was one of the first MediaWiki patches I ever made, and I don't quite like the approach I took (and it has conflicts as well). Unassigning myself as I'm not actively updating the patch and I don't want to block the implementation of this improvement.

Thank you!

At some point, T157658: Factor out a backend from EditPage will also hopefully replace the use of a DerivativeRequest in VE and other extensions, as it will be using PageEdit directly instead of calling action=edit internally. This bug still needs to be fixed though.

Since the patch that initially caused this bug has been reverted, the checkbox should be fixed with the train next week. Created T426894: Fix discrepancy between $wgRequest and the main context request in ApiEditPage to track follow-up fixes in ConfirmEdit/ApiEditPage.