Note for Editing Team: this does not affect WMF wikis

In T356599#9512522, @Esanders wrote:

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.