Update ConvenientDiscussions to use mw.libs.confirmEdit.CaptchaWidget instead of mw.libs.confirmEdit.CaptchaInputWidget
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Dreamy_Jazz
	Apr 27 2026, 11:46 PM

Project Tags

Referenced Files

None

Subscribers

Dreamy_Jazz

Jack_who_built_the_house

Description

Summary

In T422913: Rework mw.libs.confirmEdit.CaptchaInputWidget to not always require an input field, the mw.libs.confirmEdit.CaptchaInputWidget class was replaced with the mw.libs.confirmEdit.CaptchaWidget class. The latter supports hCaptcha which is being rolled out slowly to more editing interfaces. Convenient-Discussions should use the new module over the soon to be deprecated module.

Background & Technical details

mw.libs.confirmEdit.CaptchaInputWidget relies on the idea that the captcha will always have an input field to be rendered
- However hCaptcha violates this assumption as it renders it's own widget and does not use a text field for the user to enter text
- Therefore, the CaptchaInputWidget needed refactoring to support hCaptcha and a rename to make it clear that there will not always be a input field
This means that the mw.libs.confirmEdit.CaptchaInputWidget class has been deprecated and Convenient-Discussions should use the mw.libs.confirmEdit.CaptchaWidget class instead
- The CaptchaWidget class still supports all the captcha types supported by CaptchaInputWidget, so changing this does not represent a backwards step in compatibility

Acceptance criteria

Convenient-Discussions uses mw.libs.confirmEdit.CaptchaWidget instead of mw.libs.confirmEdit.CaptchaInputWidget

Related Objects
Search...

Status	Subtype	Assigned	Task
Open	Feature	Dreamy_Jazz	T356599 hCaptcha: Implement compatibility with DiscussionTools
Resolved		Dreamy_Jazz	T426229 Drop ext.confirmEdit.CaptchaInputWidget module and associated code
Resolved		Jack_who_built_the_house	T424598 Update ConvenientDiscussions to use mw.libs.confirmEdit.CaptchaWidget instead of mw.libs.confirmEdit.CaptchaInputWidget
Open		Dreamy_Jazz	T424597 Make use of the mw.libs.confirmEdit.CaptchaWidget in DiscussionTools instead of CaptchaInputWidget
Resolved		Dreamy_Jazz	T422913 Rework mw.libs.confirmEdit.CaptchaInputWidget to not always require an input field

Event Timeline

Dreamy_Jazz created this task.Apr 27 2026, 11:46 PM

Restricted Application added a subscriber: Jack_who_built_the_house. · View Herald TranscriptApr 27 2026, 11:46 PM

Dreamy_Jazz changed the task status from Open to Stalled.Apr 27 2026, 11:47 PM

Dreamy_Jazz updated the task description. (Show Details)

Dreamy_Jazz moved this task from Inbox to Triaged (backlog) on the Product Safety and Integrity board.

Dreamy_Jazz added a subtask: T424597: Make use of the mw.libs.confirmEdit.CaptchaWidget in DiscussionTools instead of CaptchaInputWidget.

Jack_who_built_the_house awarded a token.Apr 29 2026, 5:59 AM

Jack_who_built_the_house mentioned this in rMGCD64a0f5044dd0: refactor(form): prepare to support hCaptcha.May 12 2026, 6:30 PM

@Dreamy_Jazz I need to support old MediaWiki versions. How will I be able to detect whether mw.libs.confirmEdit.CaptchaWidget is functional already? Or testing for 'CaptchaWidget' in mw.libs.confirmEdit is enough?

So, as I see from your commit to DT, mw.libs.confirmEdit.CaptchaWidget works quite a bit differently from mw.libs.confirmEdit.CaptchaInputWidget,

requiring separate updating and rendering steps (with mw.libs.confirmEdit.CaptchaInputWidget, calling the constructor was enough);
requiring the container to be added to the DOM before the captcha is rendered (whereas mw.libs.confirmEdit.CaptchaInputWidget, on the contrary, supplied you with an element to add to the DOM).

Also, I won't implement initial captcha as CD users are unlikely to make their very first edit with CD, and if they are (e.g. on a new wiki, or with a new account), a failure captcha is quite enough.

Jack_who_built_the_house mentioned this in rMGCDea3a668bdc4d: feat(form): switch to mw.libs.confirmEdit.CaptchaWidget.May 12 2026, 8:30 PM

Jack_who_built_the_house mentioned this in T394115: Comment not published — Convenient-Discussions failed to display CAPTCHA.May 12 2026, 8:40 PM

In T424598#11914454, @Jack_who_built_the_house wrote:

@Dreamy_Jazz I need to support old MediaWiki versions. How will I be able to detect whether mw.libs.confirmEdit.CaptchaWidget is functional already? Or testing for 'CaptchaWidget' in mw.libs.confirmEdit is enough?

I'd recommend using mw.loader.getState as you already do in https://github.com/jwbth/convenient-discussions/blob/ea3a668bdc4dd26edef630384cd60335ce1d2458/src/loader/convenientDiscussions.loader.js#L208 but duplicate that for ext.confirmEdit.CaptchaWidget.

Then if the module is defined, it should be loaded and mw.libs.confirmEdit would contain CaptchaWidget. For older wikis without this then then the module won't be loaded and mw.libs.confirmEdit would not contain CaptchaWidget

In T424598#11914712, @Jack_who_built_the_house wrote:

So, as I see from your commit to DT, mw.libs.confirmEdit.CaptchaWidget works quite a bit differently from mw.libs.confirmEdit.CaptchaInputWidget,

requiring separate updating and rendering steps (with mw.libs.confirmEdit.CaptchaInputWidget, calling the constructor was enough);

requiring the container to be added to the DOM before the captcha is rendered (whereas mw.libs.confirmEdit.CaptchaInputWidget, on the contrary, supplied you with an element to add to the DOM).

Yes, these are both due to the extra requirements for hCaptcha:

hCaptcha requires that rendering occur once the container element exists in the DOM (if the element does not exist in the DOM it fails to work even when the container is later added to the DOM). I suspect other CAPTCHAs that may be supported later as required (such as ReCAPTCHA and Turnstile) would require this too
The separate update step was done so that you could call an update on an CAPTCHA that was already rendered and have it re-rendered only if it that is required (such as for hCaptcha)

Also, I won't implement initial captcha as CD users are unlikely to make their very first edit with CD, and if they are (e.g. on a new wiki, or with a new account), a failure captcha is quite enough.

For sure, that seems sensible to not bother with the initial captcha for CD (especially as it adds additional complexity)