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.

The solution may be to just set the wgHCaptchaTriggerFormSubmission global variable when the filter is triggered (which seems to be explicitly set to false when the page is reloaded due to the AF).

In T421041#11984534, @hector.arroyo wrote:

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

The solution may be to just set the wgHCaptchaTriggerFormSubmission global variable when the filter is triggered (which seems to be explicitly set to false when the page is reloaded due to the AF).

I don't see how it would fix testwiki? Testwiki already requires hCaptcha for account creation and the task says its inconsistent not that it never shows

That appears to be a separate issue that probably needs it own task

I wonder if its worth testing whether this is reproducable on testwiki with some of the fixes for the similar issue in the editing interfaces?

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

Change #1297652 had a related patch set uploaded (by Harroyo-wmf; author: Harroyo-wmf):

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Resubmit the form if a captcha consequence is triggered on CreateAccount

https://gerrit.wikimedia.org/r/1297652

@hector.arroyo I don't think the bug is showing the challenge without an additional submission? Can we check with Dom what they mean?

In T421041#11984763, @Dreamy_Jazz wrote:

@hector.arroyo I don't think the bug is showing the challenge without an additional submission? Can we check with Dom what they mean?

Locally, I was able to create a new account which triggered the showcaptcha consequence but did not see an hCaptcha challenge.

I attempted to reproduce on testwiki. I did see a challenge when I first submitted the form, but I am guessing it would have done this anyway, regardless of whether AbuseFilter is triggered.

I would note that production config currently does not have a different sitekey set for the AbuseFilter CAPTCHA

Change #1297692 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[operations/mediawiki-config@master] hCaptcha: Provide always challenge sitekey for account creation

https://gerrit.wikimedia.org/r/1297692

Change #1297692 merged by jenkins-bot:

[operations/mediawiki-config@master] hCaptcha: Provide always challenge sitekey for account creation

https://gerrit.wikimedia.org/r/1297692

Mentioned in SAL (#wikimedia-operations) [2026-06-04T13:33:10Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1297692|hCaptcha: Provide always challenge sitekey for account creation (T421041)]]

Mentioned in SAL (#wikimedia-operations) [2026-06-04T13:35:12Z] <dreamyjazz@deploy1003> dreamyjazz: Backport for [[gerrit:1297692|hCaptcha: Provide always challenge sitekey for account creation (T421041)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-06-04T13:38:36Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1297692|hCaptcha: Provide always challenge sitekey for account creation (T421041)]] (duration: 05m 27s)

During testing, I found that the account creation form does not have support for AbuseFilter CAPTCHAs. Additionally the issue raised by Hector above suggests that adding support for these could be counterproductive from a UI standpoint, as a user will need to retype their password when shown the challenge

I would recommend we do not implement the always challenge sitekey support to account creation, given the additional development work needed. The user will still be shown a hCaptcha widget and possibly a challenge if hCaptcha decides the user is risky enough