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

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

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.

The fact that $wgRequest and RequestContext::getMain()->getRequest() hold two different requests during an API edit is a bug and will still need to be fixed eventually, but it will probably take a bit of work to fix code that uses this as a feature, since at least ConfirmEdit is apparently doing that (T426751). I think the best solution for next week's train is to just revert the FlaggedRevs patch for now until the ApiEditPage fix is reapplied at some point and confirmed to be working fine.

If this affects the workflow of a lot of people, I think we could also revert c58febaa602036d64f05ae1f831fe08caf321d97 on wmf.2 during the UTC afternoon backport window tomorrow (and on master if the core patch I uploaded doesn't get merged before tomorrow evening, so we don't need to backport anything to wmf.3).

In T426539#11929048, @Tacsipacsi wrote:

@SomeRandomDeveloper Could this be caused by some changes around T157658: Factor out a backend from EditPage?

Looks like that fixed it, thanks!

It's a bit annoying that the URL parameters are redacted, but https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/EditPage/EditPage.php#1040 should throw an ErrorPageError if the section parameter is not empty, because this condition should then evaluate to false, unless Article::getRevIdFetched() returns the latest ID because Article::fetchRevisionRecord() hasn't been called yet at this point...

Is this new in 1.47.0-wmf.2 or did it already occur in older versions? I don't see any relevant changes in the last week in EditPage/PageEditingHelper that could've caused this

I couldn't reproduce this locally, but I found an issue with MediaHandler::fixBoxWidth(), which returns a float sometimes even though it's documented to return an int. This overrides $params['width'] at https://github.com/wikimedia/mediawiki-extensions-TimedMediaHandler/blob/c822315d877ce81b2053274697f3017a9416e68c/includes/TimedMediaHandler.php#L158, which is then used as $params['physicalWidth'] and passed to TimedMediaHandler::getSteppedThumbWidth() a few lines below.
I'm not 100% sure if this will fix the errors mentioned in this task, but it definitely looks like it could cause them.

(I missed this when filing this task, but the tests that are failing actually are part of the Cite extension, but are only failing in the Citoid repo for some reason)

I fixed this in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1225181 in January

Do we want to backport this (I could schedule it for the UTC late backport window today), or is the error rate low enough that it's not necessary and we can wait until it rolls out through the train?

I was looking at the code, and it seemed relatively trivial to fix this in parsoid and implement the behaviour of the legacy parser. (If the current behaviour in Parsoid is somehow intended (I didn't find anything relevant through git blame) and the CTT has other plans, that's also fine for me though, I made this patch primarily to learn more about the codebase, and I'm also fine with it not being merged in that case)

Test added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Score/+/1224050 for T412140, therefore tagging Wikidata-Omega

I assume this is fixed now since the patch linked above has been deployed through the train (though I can't verify that assumption myself)

Merged on Tuesday, so the parent task can probably removed as it's not blocking this week's train