This also seems to affect the crosswiki notability risk as well:

1. https://test.wikipedia.org/wiki/Special:NewArticle?newarticletitle=Karen_Foo_Kune
2. Click "Pick type instead"
3. Choose "Celebrity"

I think this also affects the subjectcovered step, although I cannot find an article to trigger this on testwiki (I don't think there are any wikidata items that have a testwiki sitelink).

In T428892#12107749, @kostajh wrote:

@dom_walden can you try one more login with Dwalden test acctcreation1 using debug mode via WikimediaDebug?

In T428892#12102971, @dom_walden wrote:

It looks like the passwords we have recorded for QTE-Test1-WMF and QTE-Test11-WMF are incorrect. I am following up.

As per T431299#12093252, as far as I can tell, I am now seeing hCaptcha when triggering badloginperuser.

In T428892#12094293, @dom_walden wrote:

There are still some users I have not been able to successfully login as, even after filling in an hCaptcha challenge. I cannot know whether the password I used was actually incorrect (although I don't think they were) or if there is still a bug.

There are still some users I have not been able to successfully login as, even after filling in an hCaptcha challenge. I cannot know whether the password I used was actually incorrect (although I don't think they were) or if there is still a bug.

As part of testing other things I have noticed that I no longer have the 120s window after triggering AbuseFilter. I didn't see any negative consequences, so far.

Fixed by this config change? I cannot reproduce this bug on testwiki nor locally after adding that line to my config.

In T429902#12089439, @Dreamy_Jazz wrote:

If you are seeing FancyCaptcha with the above then it is likely a bug. Probably also if you see this when $wgCaptchaClass is not HCaptcha because the badloginperuser should always inherit from the badlogin config (even if the generic captcha class is different)

MobileFrontend VE (ignore the black rectangle):

I don't think there is anything for me to do here that would be of much value.

I don't see this error anymore.

I don't think there is anything for me to test here.

In T429902#12089439, @Dreamy_Jazz wrote:

Locally I have the following config that is probably relevant to this:

I didn't notice any case where I saw the hCaptcha without seeing the privacy policy while testing T402595. I addition, I also did some state testing (going backward and forward, interrupting, retrying, switching between editors, etc.) of the different editors to see if I could find any edge cases. Apart from T430681, I did not notice any others.

I have retested editors (WikiEditor, VE, MobileFrontend VE and SE, DiscussionTools desktop and mobile, Android App, API), Special:UserLogin, Special:UploadWizard and Special:CreateAccount as both a user with skipcaptcha and a user without, both triggering and not triggering AbuseFilter.

I have triggered a warning on all the interfaces (WikiEditor, VE, MobileFrontend, DiscussionTools) as a skipcaptcha and temp user on testwiki.

In T429902#12064627, @Dreamy_Jazz wrote:

Sorry for the slow reply, this won't fix that issue. This ticket fixes the hCaptcha config not being copied

I retested this on testwiki for WikiEditor, VE, MobileFrontend Source and Visual, DiscussionTools (desktop and mobile) and via the API. I did it as users who did and did not have skipcaptcha rights.

This also seems to affect the Apps T430799.

In T429782#12070847, @STran wrote:

Would you mind? 🙇

In T429782#12069344, @STran wrote:

For anything that needs to load hCaptcha post-page load (VE), as long as it's not attempting to run hCaptcha's challenge before the privacy policy can be acknowledged, this is expected behavior since that code has to exist to be callable when the first POST fails.

When you try to do it on MobileFrontend Source Editor, after the second time I have seen the warning, when I click "Publish" nothing appears to happen. It can also happen after the first time you see the warning if you have already been shown the hCaptcha challenge.

As of yesterday on my local wiki and this morning on testwiki, I am not just seeing warning and showcaptcha twice, I am seeing them (possibly) indefinitely (so far about five times in a row on WikiEditor on testwiki).

In T430256#12058744, @Dreamy_Jazz wrote:

Even then I suspect this is an Upstream problem with hCaptcha. Do you see this error when you are using other interfaces?

In T429782#12058615, @Dreamy_Jazz wrote:

If you are logged into an account with skipcaptcha and then logging into an another account, then perhaps you shouldn't see the badlogin CAPTCHA but maybe I'd say you should (to avoid one account compromise making compromising other accounts easier)

@STran I am seeing hCaptcha on badlogin for a user with skipcaptcha. Is this expected, a bug or is my local environment incorrectly configured?

In T429820#12053337, @zeljkofilipin wrote:

The test you wrote (Upload stash) did run for the patch you have pushed. Was the test supposed to pass or fail without UploadWizard? (It passed.)

In T429924#12049276, @Dreamy_Jazz wrote:

The siteverify request is made server side, so if it fails you'd see an error in the mw-debug.log for local wikis and logstash for prod

@STran On VE as a user with skipcaptcha, when I trigger AbuseFilter and see the Please resubmit the form to save your edit, I notice that we are making requests to hCaptcha before we have resubmitted the form. This includes loading secure-api.js, hcaptcha-enclave.html and /checksiteconfig.

Might this fix this behaviour I just saw, after trying many failed login attempts?

Thanks. I see uselang=pt-BR opens the hCaptcha challenge with "Portuguese (Brazil)".

I can no longer reproduce this when trying many failed login attempts in a row on testwiki.

I see the "Create account" button being disabled when submitting the Special:CreateAccount form.

In T428233#12045734, @Dreamy_Jazz wrote:

I can no longer reproduce this on test.wikipedia.org. I wonder if we fixed this in other tickets?

In T429924#12047079, @Dreamy_Jazz wrote:

It suggests maybe you were seeing a hcaptcha-api error which would be the siteverify API call failing

In T429924#12045925, @Dreamy_Jazz wrote:

Perhaps we need to disable the publish button when that happens to make it clear? Though that won't fix the root cause

I can no longer reproduce.

MobileFrontend VisualEditor:

I can no longer reproduce this on testwiki.

I have tested this on testwiki.

Done with T416453.

I have tested this on Commons. I have been able to publish with mcrundo.

In T429481#12036523, @kostajh wrote:

Yes, that is OK.

With the reproduction steps in the description, I do not see a loop. Instead, it fails with error:

Error, edit not published.
There was an error while loading the form. To continue, you will need to reload the page.

@kostajh Testing locally, when I trigger an AbuseFilter with my edit I get two events recorded, the first with action=failed_edit the second with action=edit. I have seen this on WikiEditor, VE and MobileFrontend. Is this OK?

Setting $wgSkipCaptchaMinimumEditCount locally, I have checked that an autoconfirmed user with less than the required number of edits still sees hCaptcha challenges on normal and AbuseFilter edits. With more than the required number of edits, they do not see the challenge on normal or AF edits. I have only tested WikiEditor, as I assume the editing interface will make no difference.

Locally, I can see events being recorded in the event log when I attempt to login while blocked. I tested both global and local blocks.

I have done a certain amount of testing of Special:UploadWizard on testwiki. I will move this along.

I can no longer reproduce the bug in the description. I have raised T429569 for the bug described in T428437#12004543.

I was successfully able to upload an image via the API using the stash process on testwiki.

I cannot reproduce this error locally.

I can no longer reproduce.

I was successfully able to use the API to make an edit which triggered AbuseFilter. I was given a URL for a FancyCaptcha image, entered the word into captchaword and resubmitted.

@Dreamy_Jazz I notice we are missing a couple of languages from LANGUAGES_SUPPORTED_BY_HCAPTCHA which hCaptcha does support:

• pt-BR (not listed in their doc but included in the language selector in the challenge)
• zh-CN
• zh-TW

In T403829#11981364, @kostajh wrote:

@dom_walden I think this one could skip QA, but I will leave it for you to review.

I have tested Discussion Tools.

I have done a certain amount of testing of Discussion Tools. Moving along.

I do not remember seeing this problem since, although I cannot remember exactly how to trigger this bug.

I have done a certain amount of testing of this. More will be done after T428394.

I no longer see this problem. Resubmit is now automatic.

I have done a certain amount of testing of this. Moving along.

I now see more useful error messages.

Following the reproduction steps, I was successfully able to publish an edit.

@kostajh I just tested this again, and I still cannot edit on testwiki on iOS 12.

Sorry, I let this slip off my radar. Testing just now on testwiki:

Is it intentional that, after dismissing and attempting clicking Publish again, we don't go to the third page (whatever that is called) but stay on the preview page but without any loading indicator?

@Dreamy_Jazz If I dismiss the challenge and go back to the editor page, when I try to submit again the challenge does not appear and I am stuck on the preview page. Reproduced on iPhone 17 Safari and Galaxy S10 and S25 Chrome, but not on my desktop Chromium.

@kostajh One thing I notice is that if I trigger an AbuseFilter which has both the warn and showcaptcha consequences, I am shown the warning twice and have to fill in the hCaptcha challenge twice.

I also note that I don't see it working on desktop WikiEditor on Firefox 57 and below and Chrome 62 and below, presumably for the same reason as T422222. Should we have a separate ticket for Basic support?

@kostajh How can I see this working? Should I see anything on the browser-side or is it all server-side?

@Dreamy_Jazz @kostajh I haven't had much success so far getting this working on iOS or Android. So far, I have only seen it working on Galaxy S10 Android 9 Chrome. I have tried

• Lots of iPhones including iPhone 17 iOS 26.5 Safari and Chrome
• Samsung Galaxy S20 and S22 Chrome

@Dreamy_Jazz I am finding on testwiki that if I have triggered an AbuseFilter, if I make another reply after (within 120s?), regardless of whether it triggers an AbuseFilter, I have to submit the form twice, and the second time I am not given an indication I need to resubmit.