Page MenuHomePhabricator

hCaptcha: Submit button unresponsive after hCaptcha error
Open, In Progress, Needs TriagePublicBUG REPORT

Description

What is the problem?

After submitting an edit, if calling hCaptcha leads to some sort of error, the submit button becomes unresponsive. You have to reload the page.

Steps to reproduce problem
  1. Login to https://test.wikipedia.org as a user without skipcaptcha (or don't login at all)
  2. https://test.wikipedia.org/w/index.php?title=Du%C5%A1n%C3%ADky_nad_Vltavou&action=edit
  3. Trigger some sort of error in hCaptcha, for example
    1. Block requests to the url *hcaptcha.wikimedia.org (most browser devtools should support this)
    2. Make a modification to the .h-captcha element (e.g. remove the data-sitekey attribute)
  4. Click "Publish changes"

Expected behaviour: You will see some sort of error. If you undo whatever you did in step 3 you should be able to try to submit again and be successful.
Observed behaviour: After seeing an error, clicking "Publish changes" again will do nothing.

Environment

Browser: Chromium 141.
Wiki(s): https://test.wikipedia.org ConfirmEdit 1.6.0 (rECOE7a69824f612f) 21:36, 11 November 2025.
Editor: WikiEditor 0.5.4 (7375527) 07:51, 6 November 2025.

Event Timeline

Alternatively, you can switch the browser to Offline mode in the dev tools after the captcha popup has been shown but before clicking the Verify button.

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

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Handle network errors as recoverable

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

An initial patch (pending tests) was submitted to cover the case when the hCaptcha client lib reports a network error, so that the user is able to resubmit the form in this scenario: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186

I still need to do more tests locally to reproduce and fix the case when the site key is manually removed from the DOM.

hector.arroyo renamed this task from hCaptcha: submit button unresponsive after hCaptcha error to hCaptcha: Submit button unresponsive after hCaptcha error.Fri, Nov 14, 4:12 PM

I've updated https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186, which is ready for review.

For the second case (Make a modification to the .h-captcha element), I tested by removing the key from the DOM before clicking in the form as well as by providing a wrong value (so that preloading the SDK happens with the wrong key already set).

  • With this patch, the user gets an error "There was an error while loading the form. To continue, you will need to reload the page".
    • This happens because the SDK cannot be loaded with a wrong key, and it does not seem there's much we can do about that: The key gets "fixed" to the wrong value, so even if we then put back the wrong key the SDK would not try to load it again with the correct one (it attempts a request to https://api.hcaptcha.com/getcaptcha/the-wrong-key that results in a 403 (Forbidden) and gives up trying to load the SDK).

If, instead, I first click in the form and then edit the DOM in order to remove the site key, the captcha still works, likely because the SDK already "saved" the correct sitekey during the SDK preload. In any case, I'm not trying to address the case for removing the sitekey from the DOM, as it seems something unlikely to happen in a real scenario.

For the first case (Block requests to the url *hcaptcha.wikimedia.org), with the patch, I tested by using the Dev Tools for putting the browser in Offline Mode instead after the captcha is loaded but before sending it. Doing so, the new patch shows an error "There was a network error while sending the form. Please, ensure you have a working connection and try again" (introduced by the patch above, here). Re-enabling the connection and trying to save the eidt results in a new captcha being shown which, once solved, allows to correctly save the edit.

@Niharika @EMill-WMF @kostajh I was thinking on using these messages for the errors raised during the hCaptcha execution:

"hcaptcha-internal-error": "There was an internal error while sending the form. Please, try again."
"hcaptcha-network-error": "There was a network error while sending the form. Please, ensure you have a working connection and try again."
"hcaptcha-rate-limited": "There have been too many attempts to solve the captcha. Please, wait a moment before trying again."

Does that sound ok to you?

If not, we can keep using the current generic message There was an error while loading the form. To continue, you will need to reload the page. or a new generic message stating that the user may retry the submission (something like There was an error while loading the form. Please, try again).

I've updated the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186 to keep using the generic message for these cases ("There was an error while loading the form. To continue, you will need to reload the page.") while still allowing the user to resubmit the form.

@Niharika @EMill-WMF @kostajh I was thinking on using these messages for the errors raised during the hCaptcha execution:

"hcaptcha-internal-error": "There was an internal error while sending the form. Please, try again."
"hcaptcha-network-error": "There was a network error while sending the form. Please, ensure you have a working connection and try again."
"hcaptcha-rate-limited": "There have been too many attempts to solve the captcha. Please, wait a moment before trying again."

Does that sound ok to you?

If not, we can keep using the current generic message There was an error while loading the form. To continue, you will need to reload the page. or a new generic message stating that the user may retry the submission (something like There was an error while loading the form. Please, try again).

I've updated the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186 to keep using the generic message for these cases ("There was an error while loading the form. To continue, you will need to reload the page.") while still allowing the user to resubmit the form.

The patch is using the pre-existing, generic message for these cases, since I think that was the agreement reached during previous discussions. Please do open a new ticket in case the wording needs to be updated to have a custom message depending on the particular error that happened (i.e. network error, hitting the rate limit, etc).

Note that concerns have been raised about the inability of sending the form if the connection is lost after loading the edit form but before the used interacts with it (i.e. before there is a chance to load hCaptcha's SDK). This discussion is blocking merging that patch.

Note that concerns have been raised about the inability of sending the form if the connection is lost after loading the edit form but before the used interacts with it (i.e. before there is a chance to load hCaptcha's SDK). This discussion is blocking merging that patch.

@hector.arroyo Is this still blocking the patch?

"hcaptcha-internal-error": "There was an internal error while sending the form. Please, try again.",
"hcaptcha-network-error": "There was a network error while sending the form. Please, ensure you have a working connection and try again.",
"hcaptcha-rate-limited": "There have been too many attempts to solve the captcha. Please, wait a moment before trying again.",

This is fine, but could we please remove the commas after Please, in these messages? They should read:

"hcaptcha-internal-error": "There was an internal error while sending the form. Please try again.",
"hcaptcha-network-error": "There was a network error while sending the form. Please ensure you have a working connection and try again.",
"hcaptcha-rate-limited": "There have been too many attempts to solve the captcha. Please wait a moment before trying again.",

@hector.arroyo Is this still blocking the patch?

It isn't: We removed the changes in the 18n messages on Wednesday, and now it just introduces the retry logic but keeps using the old messages.

However, as the patch is still not merged, I will update it to use the new messages

@EMill-WMF confirmed that the new messages are correct (the new messages are the same as before but without commas, i.e. "Please try again" instead of "Please, try again").