This is working as expected in the master branch of MobileFrontend.

This is working as expected (tested locally with the master branches of the MobileFrontend and ConfirmEdit).

If I first clear cookies and then repeat the test:

The issue is only occurring if the first widget does not use the always challenge sitekey

I get the same result both in Chrome and in Firefox

I've tested by closing the challenge manually (the ticket says when the hCaptcha challenge shows, dismiss it (click away or press Esc)).

I've pulled the latest master branches for ConfirmEdit (CAPTCHA extension) and MobileFrontend and retested this locally, and this is working as expected in my local environment: If I open the consequence by typing "showcaptcha" in the summary, clicking outside the captcha (or pressing Esc), then trying to submit again shows a new captcha. Then, the edit is saved after solving it.

We've deployed a change to use a new interface name for the MobileFrontend and now it seems the subscriber for the confirmEdit.hCaptchaRenderCallback event in the MobileFrontend is working as expected. I'm closing this task now.

I'm not able to reproduce this locally, but I can reproduce it on test.wikipedia.org.

Anyway, we can't just re-submit the CreateAccount form automatically since, on page reload, the password field and its confirmation come empty (unless we are ok with writing the user-provided password in the HTML we send back with the error -- probably we shouldn't since the current implementation explicitly avoids doing so; or unless we implement an additional mechanism to temporarily store the user-submitted password in the user session for retrieving it back in SpecialCreateAccount if the field comes empty (which still feels potentially dangerous)).

Locally,

• ✅ Setting $wgCaptchaTriggers['createaccount']=true and having a filer with account_name contains 'AF' as the condition works as expected (it seems to just trigger the normal createaccount action)
• ❌ Setting $wgCaptchaTriggers['createaccount']=false and having the previous filter fails (it goes back to the form with an "Incorrect or missing CAPTCHA" error). Trying to submit the form the second time shows the captcha, solving it creates the account correctly.

With the following changes applied:

• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1290753 (the one for this ticket)
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1292018 (T426069: hCaptcha risk scores: Handle events for risk scores obtained for blocks in CaptchaScoreHooks, to make MF trigger a frontend hook when a block notice is shown).

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1290753 was merged

In T426068#11975361, @Dreamy_Jazz wrote:

What about QA?

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1290031 was merged, closing this task

This was done in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1290031 as part of T426068: hCaptcha risk scores: New API endpoint for collecting risk scores. That patch is now merged and the related task is closed, so closing this one too.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1295993 & https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1290031 were merged, closing this task

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/1288971 was merged, closing this task.

The schema update from T426071: hCaptcha risk scores: Schema update for risk_score events has been merged, so this is no longer blocked.

In T427087#11960570, @Dreamy_Jazz wrote:

What about updating the module handler for MobileFrontend to only load the hCaptcha SDK when the editor actually appears and is usable?

I think this happens because https://gerrit.wikimedia.org/g/mediawiki/extensions/ConfirmEdit/+/master/includes/Hooks/Handlers/MakeGlobalVariablesScriptHookHandler.php does not check it the user is blocked but only if HCaptcha is enabled for the MobileFrontend. However, that behavir will be required for collecting hCaptcha risk scores, so I'm not sure a fix for this would be needed (maybe we could skip loading the modules if the user is blocked and HCaptchaBlockedIpEditingScoreCollectionSiteKey is not set )

Revert here: https://gerrit.wikimedia.org/r/c/integration/config/+/1294335

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1288955 was merged, closing this ticket

The CI config change https://gerrit.wikimedia.org/r/c/integration/config/+/1292060 was merged today morning, closing.

CI errors in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1292052 seem to be caused by DiscussionTools, submitting a patch on that repo with no functional changes currently make the CI fail there: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1292872, https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83-phpunit-standalone/6735/console