It's maybe a good idea to change the registration of modules, removing the OutputPage completely (or the context itself) could lead into problems. ReCaptchaNoCaptcha for example uses the OutputPage object to add a required JS module (which is loaded from Google dierctly buhhhh!!!!), see https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/ReCaptchaNoCaptcha/ReCaptchaNoCaptcha.class.php#L22-L25.

So we should probably just change the return value of getForm to an array and return the HTML and the modules. If we do it as an associative array, instead of a numbered one, we could also be prepared for the future, where probably other information needs to be returned, too :)

In T141300#2493917, @Florian wrote:

So we should probably just change the return value of getForm to an array and return the HTML and the modules. If we do it as an associative array, instead of a numbered one, we could also be prepared for the future, where probably other information needs to be returned, too :)

We can remove the OutputPage parameter and still support the weird ReCAPTCHA case, using "headitems".

Related (to the headitems): https://gerrit.wikimedia.org/r/#/c/301028/1

Good argument!

Change 301147 had a related patch set uploaded (by Florianschmidtwelzow):
Deprecate getForm() and replace by getFormInformation()

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

From reviewing https://github.com/search?q=org%3Awikimedia+getForm&type=Code , the only Gerrit-hosted extensions affected are:

• Flow (WMF-deployed, and that's the root cause :) ) - https://github.com/wikimedia/mediawiki-extensions-Flow/blob/3df503188cb6a9654e9136e866cdfb5057fbc17b/includes/SpamFilter/ConfirmEdit.php - T140472: Flow: Update to stop using buildCssLinks and for related ConfirmEdit change
• Wikilog (it is in Gerrit, but https://phabricator.wikimedia.org/project/manage/399/ points to mediawiki4intranet, so OK) - https://github.com/mediawiki4intranet/Wikilog/blob/ec19029cf3f5f28517c0dac73d3d18a3004667ff/WlCaptchaAdapter.php (already broken from 36abbc628834ae141f9c28f0bc3d2c8d44524754 in ConfirmEdit) - https://github.com/mediawiki4intranet/Wikilog/issues/17 . Fixed at https://github.com/mediawiki4intranet/Wikilog/pull/18 , but this extension is already out of date for other reasons.
• WikiForum - https://github.com/wikimedia/mediawiki-extensions-WikiForum/blob/d842d1354d20bf7a9adf3cb5236c719a0a0b0ec7/WikiForumClass.php - T141416: WikiForum: Stop using getForm due to ConfirmEdit changes
• ContactPage (WMF-deployed) - https://github.com/wikimedia/mediawiki-extensions-ContactPage/blob/f39659bad40a1492224265687468acbddcb1c854/ContactPage_body.php - T141417: ContactPage: Stop using getForm due to ConfirmEdit changes
• ConfirmAccount - https://github.com/wikimedia/mediawiki-extensions-ConfirmAccount/blob/32dc740ef0d8233006221d244e98857fb32f7496/frontend/specialpages/actions/RequestAccount_body.php - T141418: ConfirmAccount: Stop using getForm due to ConfirmEdit changes

I'll fix these, but only the WMF-installed ones absolutely must be merged at the same time (the others would be good so they don't languish, though).

@Krinkle Can you check that the ConfirmEdit patch doesn't cause a regression for VisualEditor. Stand-alone VE isn't working for me locally at the moment.

At least from my testing with VE, there're no differences or problems. But it would be good to have someone, who is more familar with VE, to recheck, as I simply tried to edit and solved the CAPTCHA, once with master and once with the change applied :)

Change 301147 merged by jenkins-bot:
Remove getForm() and replace by getFormInformation()

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

Checking in betalabs - cannot trigger Captcha for edits.
Although Special:Version shows that ConfirmEdit is installed in beta. @Mattflaschen-WMF - something should be added/enabled in CommonSettings.php ?
The scenarios that I'd like to check are in
https://www.mediawiki.org/wiki/Extension:ConfirmEdit/Test_Plan

General scenario:

• as a user that belongs only to Users group, edit a page in VE mode
• click 'Save page' - Captcha should appear.

In T141300#2533725, @Etonkovidova wrote:

On English Wikipedia on Beta Cluster, we have:

var_export( $wgCaptchaTriggers );
array (
  'edit' => false,
  'create' => false,
  'sendemail' => false,
  'addurl' => true,
  'createaccount' => true,
  'badlogin' => true,
  'badloginperuser' => true,
)

This is the same as production.

You can test:

• Adding a URL when editing
• Creating an account
• Repeatedly getting the login password wrong.

It is not configured to trigger on all edits.

Checked Captcha in betalabs for creating accounts/multiple login attmepts - all works as expected.