An user informed me he was unable to edit a wiki that is my responsibility using the mobile interface provided by mw:Extension:MobileFrontend, when not logged in.

After looking into the issue a little bit and also receiving help, it seems to be because the MobileFrontend does not correctly include the CAPTCHA provided by/via mw:Extension:ConfirmEdit.

See irc log cutlets at end for some proficient insight on the issue from _tgr

Steps to Reproduce:

1. Activate ConfirmEdit and MobileFrontend
2. Set CAPTCHA type to ReCaptchaNoCaptcha or hCaptcha
3. Access wiki in mobile mode and try to do something for which CAPTCHA should be invoked.

Actual Results:

1. A box stating "Enter confirmation code" shows up, no CAPTCHA

Expected Results:

1. CAPTCHA is served to mobile users normally.

Information:

This is probably due to mw:Extension:MobileFrontend not fully supporting mw:Extension:ConfirmEdit. This seems to be a semi-known issue.

The documentation of MobileFrontend does not claim that it supports ReCaptchaNoCaptcha, but the ones it supports are even weaker and we are having problems of bots passing the current CAPTCHA. hCaptcha could be more suitable.

I hope this can be fixed. Also any solid-ish workaround solution would be helpful.

Relevant wiki configuration :

MediaWiki version: 1.35.1 (ffed6e6) 07:03, 8 January 2021

$wgMFAutodetectMobileView = true;
$wgMFAdvancedMobileContributions = true;
wfLoadSkin( 'MinervaNeue' );
$wgMFDefaultSkinClass = 'SkinMinerva'; 
wfLoadExtension( 'MobileFrontend' );

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';

Some related tickets I came across when searching for info / existing tickets

• Mediawiki Topic:Uk1vm2ln781c0jat MediaWiki support desk topic ''ReCaptchaNoCaptcha support for VisualEditor?'' lead to ticket [https://phabricator.wikimedia.org/T203478 T203478 - ''Support No CAPTCHA reCAPTCHA in VisualEditor''] - marked as closed resolved and resulted in [https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/478288/ Patch 478288 to ConfirmEdit]
• https://phabricator.wikimedia.org/T128487 T128487 - ''Support more CAPTCHA modules of ConfirmEdit in the Api'' - open, low
• https://phabricator.wikimedia.org/T64960 T64960 - ''Prototype CAPTCHA optimized for multilingual and mobile'' - open, medium
• https://phabricator.wikimedia.org/T160262 T160262 - ''Add support for Google's new Invisible reCAPTCHA'' - open, medium

Relevant parts from irc conversation in the mediawiki-mediawiki channel on freenode on 2021-02-07

(used with permission, redacted irrelevant parts, my nick is Iamahuman)

• [sunnuntaina 7. helmikuuta 2021] [15.02.42 EET] <Iamahuman> Hi. An user just contacted me an informed me that he is unable to submit changes anonymously on mobile. The text "enter confirmation code’ appears, no CAPTCHA. Am Using reCAPTCHA v2 iirc
• [sunnuntaina 7. helmikuuta 2021] [15.04.31 EET] <Iamahuman> I googled for it and found it on line 41 of https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/i18n/en.json. The line reads as follows: "mobile-frontend-account-create-captcha-placeholder": "Enter confirmation code",
• [sunnuntaina 7. helmikuuta 2021] [16.24.14 EET] <tgr_> Iamahuman: are you using ConfirmEdit?
• [sunnuntaina 7. helmikuuta 2021] [16.28.38 EET] <Iamahuman> tgr_: Yes, I am
• [sunnuntaina 7. helmikuuta 2021] [16.29.06 EET] <Iamahuman> and the reCAPTCHA invisible captcha does not work for my mobile users
• [sunnuntaina 7. helmikuuta 2021] [16.30.35 EET] <tgr_> is it a public wiki?
• [sunnuntaina 7. helmikuuta 2021] [16.30.40 EET] <Iamahuman> yes
• [sunnuntaina 7. helmikuuta 2021] [16.31.45 EET] <tgr_> Iamahuman: can you share a link?
• [sunnuntaina 7. helmikuuta 2021] [16.31.49 EET] <Iamahuman> tgr_: https://develop.consumerium.org/wiki/Main_Page
• [sunnuntaina 7. helmikuuta 2021] [16.33.17 EET] <tgr_> oh, you are using ConfirmAccount?
• [sunnuntaina 7. helmikuuta 2021] [16.36.18 EET] <Iamahuman> tgr_: Using ConfirmAccount and ConfirmEdit ... hordes of bots hit in 2008 and 2010
• [sunnuntaina 7. helmikuuta 2021] [16.40.04 EET] <tgr_> Iamahuman: oh, sorry, I thought the problem was during signup. I see now you were talking about editing.
• [sunnuntaina 7. helmikuuta 2021] [16.40.32 EET] <tgr_> That's pretty hopeless, MobileFrontend replaces the edit interface entirely.
• [sunnuntaina 7. helmikuuta 2021] [16.43.16 EET] <tgr_> I suppose you can intentionally break MobileFrontend's routing
• [sunnuntaina 7. helmikuuta 2021] [16.43.38 EET] <tgr_> something like https://develop.consumerium.org/w/index.php?title=Research/US/How_to_find_out_who_owns_what&action=edit#/xxx won't get hijacked because there already is a route
• [sunnuntaina 7. helmikuuta 2021] [16.43.55 EET] <tgr_> so maybe you can add that to edit links somehow
• [sunnuntaina 7. helmikuuta 2021] [16.44.07 EET] <tgr_> or maybe there's a proper way to disable the edit overlay in MF
• [sunnuntaina 7. helmikuuta 2021] [16.46.45 EET] <Iamahuman> tgr_: I don't quite understand it, but that link you posted, in a non-logged-in browser, does show the reCAPTCHA, whereas normally it doesn't show up
• [sunnuntaina 7. helmikuuta 2021] [16.47.01 EET] <Iamahuman> in the mobile view
• [sunnuntaina 7. helmikuuta 2021] [16.47.35 EET] <tgr_> yeah because it has a fake route, which prevents the MobileFrontend logic from rerouting it to the mobile edit form
• [sunnuntaina 7. helmikuuta 2021] [16.48.22 EET] <tgr_> another trick would be to create an edit link with action=submit instead of action=edit
• [sunnuntaina 7. helmikuuta 2021] [16.52.11 EET] <Iamahuman> rather no tricks, but a reliable documented way of circumnavigating this problem
• [sunnuntaina 7. helmikuuta 2021] [16.53.58 EET] <Iamahuman> At least now I know of this problem, previously I had no idea of this existing. Hopefully someone fixes it. It would seem to me (but not sure) that the Mobile Frontend should somehow be different so that the CAPTCHA would be displayed as it is to web users
• [sunnuntaina 7. helmikuuta 2021] [19.47.18 EET] <Iamahuman> [18:00] <tgr_> Iamahuman: MobileFrontend implements its own edit form. It would have to implement its own captcha handling too. Or rather, provide a hook point (maybe it does that already) for ConfirmEdit to implement.