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.

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

I can still reproduce on:

• Firefox 151 Windows 11
• Firefox 109 Windows 8.1
• Firefox 140 Debian 12

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?

@hector.arroyo Is there anything I should be seeing right now? I am attempting to edit a page on mobile as a blocked user, seeing a block message, but I cannot see any requests in devtools that seem related to this change (e.g. no request to /confirmedit/v0/hcaptcha/blocktoken). I have tried testwiki and my local wiki.

In T373498#11973518, @Rajveer42 wrote:

Would you like me to proceed with this, or would you prefer a separate flag like --no-consequence?
Will keep the patch single-file plus the test update.

On testwiki without these fixes:

1. Open a DT reply or new topic
2. Make trigger AF disallow consequence by writing disallow in edit summary
3. See warning from AF that I have triggered a filter
4. Remove disallow from edit summary so AF is not triggered
5. Attempt to submit reply: unsuccessful
6. Attempt to submit reply again: successful

I can no longer reproduce this locally.

Unfortunately, I don't see how I can test this. I will move it along.

I have not seen this happen on testwiki so far

In T422222#11955035, @kostajh wrote:

Did you have to override the security policy for Firefox 49 with regards to the SSL cert? If you visit each subdomain (e.g. assets-hcaptcha.wikimedia.org, hcaptcha.wikimedia.org, img-hcaptcha.wikimedia.org, etc) that you see in the network requests tab, and accept the security override, then it should work.

In T422222#11954208, @kostajh wrote:

Thanks for letting me know. I've seen this too. This one might relate to peculiar issues with the networking set up between client / BrowserStack / WMF proxy, rather than grade C compatibility. Could you retry it on testwiki please?

In T422222#11945319, @kostajh wrote:

In T422222#11945255, @gerritbot wrote:

Change #1290793 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Avoid `for (const ... of ...)` in Grade C bundle

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

This should fix the Firefox 50 and 49 cases noted above; still working on Chrome 50 and 49.

In T422222#11941348, @kostajh wrote:

@dom_walden desktop wikitext editor and Special:CreateAccount should usable now via a Grade C browser, can you please test this in your local environment, and/or verify it next week when the train is at group0? Thank you!

In T423287#11925774, @kostajh wrote:

Config patch for T426178: hCaptcha: Failed to load resource: Origin (domain) is not allowed by Access-Control-Allow-Origin is now live, would you mind retesting on iOS 12 again please?

In T426751#11940391, @kostajh wrote:

@dom_walden can you please try to reproduce this issue again?

In T426587#11931008, @kostajh wrote:

In T426587#11930165, @kostajh wrote:

The addurl action in ConfirmEdit uses the same 99.9% passive mode SiteKey as editing, so unless hCaptcha is suspicious of your session, you should not see a challenge. I'm not sure why this is being triggered on VE and mobile source editor. That seems like the bug.

@dom_walden can you please retest? The config patch is syncing out now. The behavior should be the same across all editing interfaces: adding a URL uses the 99.9% passive mode detection approach, and does not go into "always challenge" mode for all of the editing interfaces.

I can no longer reproduce this locally.

On testwiki, I have tried editing on various versions of Chrome from 64 to 81 and I was able to successfully publish in the WikiEditor, completing the hCaptcha challenge when necessary.

Tested as part of T424651.

I see the back button is disabled while hCaptcha is loading. On testwiki and locally.

Sorry, I am confused.

I still see two challenges, but if that is intentional then I guess it is OK.

On testwiki, I have experimented with closing the save dialog in various cases. I was always able to reopen the dialog and save successfully.

I haven't seen this issue since on various mobile devices.

@hector.arroyo I tested this last week and I could not reproduce. However, testing this again this morning on testwiki and locally, I can reproduce it. Firefox, Chromium and Chrome on Samsung Galaxy S26.

In T423287#11916427, @dom_walden wrote:

I also notice just now that I can no longer edit on iPhone 11 iOS 13 on mobile Source and Visual Editor. It becomes unresponsive when trying to publish the page.

I also notice just now that I can no longer edit on iPhone 11 iOS 13 on mobile Source and Visual Editor. It becomes unresponsive when trying to publish the page.

I have seen this fairly reliably when editing (on desktop and mobile VE and SE), either when doing an edit which triggers addurl or AbuseFilter or a normal edit which triggers an hCaptcha challenge.

It would be great to retest this on testwiki, trying to find as many places/states where you can cancel the hCaptcha loading or dismiss the challenge (particularly using esc or similar). The below diagram may give you some inspiration. We want make sure that a user can always successfully publish an edit.

I no longer see this.

I see this happening now.

Someone could double check this on testwiki (Maxim might already have done this).

I have not seen this error anymore, although I have not been monitoring it consistently.

It would be great if someone could check this on testwiki.

I have only tested on testwiki or local wiki with a relatively production like config.

I have not seen this problem since. I can edit the same article on testwiki multiple times.

Can someone check on testwiki that an autoconfirmed user can use all the editing interfaces (mobile and desktop source and visual editors), that no hCaptcha related requests are being sent, that no hCaptcha challenge is shown (obviously) and they can successfully publish an edit.

It would be great if someone with access to physical mobile devices could test how well hCaptcha works with gestures like pinch to zoom, etc.

I don't fully understand this change. However, I have certainly seen the hCaptcha loading both on initial click of "Publish changes" and on the second click (after you have seen the "Please resubmit..." message). @Dreamy_Jazz Is there anything else?

I have not paid much attention to which events are being fired in which editors and under which circumstances. Therefore, a developer could take this up.

This can be moved on as testing has been/is being done elsewhere.

I have seen the AF and addurl consequences work many times on VisualEditor desktop and mobile on testwiki.

I have seen the addurl and AbuseFilter consequences on mobile source editor.

I don't really know about this, so a developer could pick this up.

This look ok on testwiki on both mobile source and visual editors.

@hector.arroyo Testing locally, after dismissing (either by clicking away or pressing esc) the challenge and being returned to the edit summary page, clicking the Save/Publish button does not seem to do anything. I see some calls to hCaptcha being made but nothing appears on screen (perhaps it is hidden?)

I might be able to reproduce this on mobile and desktop visual editor, where for the next edit after triggering AF the hCaptcha is triggered on the "Please resubmit" page.