Page MenuHomePhabricator

hCaptcha: Implement compatibility with DiscussionTools
Closed, ResolvedPublicFeature

Description

Steps to replicate the issue (include links if applicable):

  • Enable ConfirmEdit and choose the "hCaptcha" option
  • Be logged in
  • Attempt to use the "Reply" function in DiscussionTools

What happens?:

image.png (870×300 px, 20 KB)
appears

What should have happened instead?:
hCaptcha's UI should appear as it does on pages such as Special:CreateAccount

Software version (skip for WMF-hosted wikis like Wikipedia):

Product Version
MediaWiki 1.40.2 (13bc5ff)
22:43, 30 January 2024
PHP 8.2.7 (fpm-fcgi)

Other information (browser name/version, screenshots, etc.):

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Pppery renamed this task from DiscussionTool is incompatible with hCaptcha (and likely ReCaptcha) to DiscussionTools is incompatible with hCaptcha (and likely ReCaptcha).Feb 4 2024, 9:37 PM
Pppery updated the task description. (Show Details)

Note for Editing Team: this does not affect WMF wikis

Note for Editing Team: this does not affect WMF wikis

And it never should affect Wikimedia production, as the current ConfirmEdit integration with hCaptcha is far too basic to satisfy all of the technical concerns outlined in T250227 and elsewhere.

I believe the bug currently lies in DiscussionTools.

For VisualEditor, ConfirmEdit handles displaying the captcha. ve.init.mw.CaptchaSaveErrorHandler.js handles SimpleCaptcha and QuestyCaptcha (by using ext.confirmEdit.CaptchaInputWidget.js, a multi-purpose CAPTCHA text box), and ve.init.mw.HCaptchaSaveErrorHandler.js handles hCaptcha. All save error handlers are tested by VisualEditor as the modules register a hook with VE, and one is used based on the return value of matchFunction.

In contrast, DiscussionTools handles CAPTCHAs by only using ext.confirmEdit.CaptchaInputWidget (see dt.ui.ReplyWidget.js line 1085). This input widget only supports textboxes, while hCaptcha (and probably reCaptcha) uses an iframe.

A workaround would be to hardcode exceptions for hCaptcha and reCaptcha in DiscussionTools, and use their hooks somehow. A proper fix would be to either add hooks into DiscussionTools, or to reuse VisualEditor's.

OOI, does this actually prevent using DiscussionTools with hCaptcha (or similar) enabled? Or does it just present an ineffective captcha (that can't be solved, and therefore doesn't prevent stuff that it maybe should've)...

DiscussionTools can't properly display the captcha if it is given one, but otherwise it should work if there is no captcha presented to it. (Un)fortunately, there is no captcha bypass when using DT.

Now we're working on getting into hcaptcha into production for a trial, this bug is becoming more of a blocker because we'd really like to test it on edits. We aren't going to be ready for another quarter but if this was fixed we could do some more interesting experiments to show how well hcaptcha can protect against spam edits.

@Esanders just talking about this with Reedy, we think the fix might be similar to how VisualEditor fixed it but we don't really have the javascript expertise to figure it out. Is there any chance we could get this fixed early Q4?

I also just encountered this one :(

kostajh renamed this task from DiscussionTools is incompatible with hCaptcha (and likely ReCaptcha) to hCaptcha: Implement compatibility with DiscussionTools.Sep 25 2025, 1:43 PM
kostajh removed a subscriber: acooper.
kostajh set the point value for this task to 0.75.Sep 30 2025, 11:48 AM
kostajh changed the task status from Open to Stalled.Sep 30 2025, 11:52 AM
kostajh subscribed.
SomeRandomDeveloper changed the task status from Stalled to Open.Oct 23 2025, 10:49 PM

That task has been resolved since, so I assume this is no longer stalled.

Dreamy_Jazz changed the subtype of this task from "Bug Report" to "Feature Request".Apr 27 2026, 11:50 PM