(Moving to Ready as code review was given but patch has sat without activity for a while)

Reopening this one because in T356599: hCaptcha: Implement compatibility with DiscussionTools we will only focus on hCaptcha

I'm not a big fan of the content flash that appears, as the button is disabled for me for only a very short time but long enough to appear as a flash on the page.

AFAICS this should be sorted? Tentatively resolving

I'm not sure what test coverage was being aimed for, but given the parent task is closed as declined and https://doc.wikimedia.org/cover-extensions/StopForumSpam/index.html lists 25% coverage (better than about half of extensions) I think this could probably be resolved

Being fixed through T407202: hCaptcha VisualEditor: Execute hCaptcha when in invisible mode mode if hCaptcha widget shown before first "Save changes" attempt

We've got it working in a doable way for WMF wikis, so we will implement the designs as specified above for WMF wikis. For third-party wikis (that do not use enterprise hCaptcha) we will have to expand the dialog, as it's not possible to render the challenge outside the dialog.

RecentChanges defaults categorisation changes to be marked as a bot due to T109700. This only changes if the recent change for the associated edit can be found when the categorisation one is created and that recent change is also marked as not a bot action

In T418220#11797134, @Jdlrobson-WMF wrote:

I see this is marked as "Done" but not resolved. Anything left?

In T422553#11796616, @HakanIST wrote:

Looking at the code, the root cause seems to be that getLocalStatusInfo() returns a truthy array for wikis in $wgGlobalBlockingWikisWhereGlobalBlocksDoNotApply, which CentralAuth then displays as a real exemption.

We have some options:

1. We hide this on Special:CentralAuth for all users
2. We hide this on Special:CentralAuth for Stewards only
3. We hide this on Special:CentralAuth just for WMF wikis

In T422220#11795902, @Johannnes89 wrote:

In T422220#11794995, @Dreamy_Jazz wrote:

https://meta.wikimedia.org/wiki/Special:CentralAuth/Faster_than_Thunder loads now, closing

@Dreamy_Jazz the immediate issue has been resolved, but with an unintended result – "Wikis exempt from global block" should only list those which locally disabled the global block. It now shows a list of closed wikis + meta wiki (where global blocks never apply).

There might even be a feature in telling users that global blocks don't apply to metawiki (sometimes people are confused why globally blocked users can still edit on metawiki), but personally I don't think the issue is important enough to do that. We now have to scroll by this block before looking at the global account status and list of local accounts for every globally blocked account...

I'd file a new task for this instead of reopening this task, because this is about the exception that was seen.

Haven't seen any more logs since the deployment of the fix to all wikis. Can reopen if logs are still occurring, but tentatively resolving as fixed for now

https://meta.wikimedia.org/wiki/Special:CentralAuth/Faster_than_Thunder loads now, closing

Seems like it

Breaks Special:CentralAuth for all users who have accounts on closed wikis

In T422220#11787749, @matmarex wrote:

I feel like this should be handled in the getLocalStatusInfo() method in GlobalBlocking. Maybe just a tableExists() check would be enough.

In T421579#11783186, @Wellverywell wrote:

I'm pretty sure the global community, same as me and the ticket's author, finds words naming much easier to keep in mind then the numbers one. I don't see why there would be a need in "two name formats" that need to be supported.

Yeah, MediaWiki-extensions-CentralAuth probably needs updating to have a list of wikis where GlobalBlocking is installed and only query from those (it currently assumes it's installed on every wiki that MediaWiki-extensions-CentralAuth would be able to show).

In T418220#11783969, @Jdlrobson-WMF wrote:

Should we revert https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1243072 ?
We don't show temporary accounts in Wikimedia production to legacy Vector skin and don't support using non-default skins for temporary accounts so this code supports third parties and is not being actively tested.

I think this should probably be in ConfirmEdit (CAPTCHA extension) instead of MobileFrontend, because Product Safety and Integrity own ConfirmEdit (CAPTCHA extension) and these would be out selenium tests to manage