Page MenuHomePhabricator

Fix discrepancy between $wgRequest and the main context request in ApiEditPage
Open, Needs TriagePublic

Description

ApiEditPage sets $wgRequest to the API request when being executed, but it doesn't update RequestContext::getMain()->getRequest().

As a result of this, when code in FlaggedRevs was updated to use RequestContext::getMain()->getRequest() instead of $wgRequest in c58febaa602036d64f05ae1f831fe08caf321d97, it broke the "Review pending changes" checkbox when using VisualEditor (T426539), as VE uses a DerivativeRequest to call action=edit internally when an edit is submitted.

A fix for this was attempted in 4675b694527ee5de30775c584d2858564a46c544, which updated ApiEditPage to set the main request to the API request as well, but it had to be reverted because it caused T426751: Stuck in FancyCaptcha challenge loop on VisualEditor. ConfirmEdit (and potentially other extensions) should be fixed so they don't rely on this discrepancy anymore.

Event Timeline

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 they will be using PageEdit directly instead of calling action=edit internally. This bug still needs to be fixed though.

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