After discussion on slack we've decided that this would not be good from a UX point of view.

Partial fix in https://phabricator.wikimedia.org/T425701

Chrome 63 or less don't get js served anymore https://gerrit.wikimedia.org/r/c/mediawiki/core/+/904851, can only fix for Chrome 64+
Ssee https://phabricator.wikimedia.org/T178356 when this change was implemented

Works on Chrome 67, broken in Chrome 64 and 66.

Looks like support for these old browsers was removed on purpouse in https://phabricator.wikimedia.org/T344791

Login is broken in Chrome 62

Weird behaviour, on first "cold" login it fails and gives the warnings, even though the password is 100% correct, because I copy pasted it. It also also to solve the word-captcha.
If you try to logout/login again afterwards it works just fine on first try.

It gives that error as mentioned when you're logged as a normal user, but it works fine as user with skip-captcha permission in Firefox 57

That warning should be fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OATHAuth/+/1281397

On Firefox 56-57 works from first try, even though that warning Javascript must be enabled in your browser to use a security key is there

First attemped it shows the error from the screenshot, but on retrying it works

Here is how it looks

I just tested on
https://test.wikipedia.org/w/index.php?title=Portugal_in_the_Junior_Eurovision_Song_Contest#/editor/all that it now works correctly on Chromium Version 147.0.7727.116 (Official Build) snap (64-bit) it seems the menu now works in Arabic

Tested as https://test.wikipedia.org/wiki/User:MPostoronca-WMF on mobile/desktop in visual/source editor, with the keyword 'testcaptcha' (because of the rule https://test.wikipedia.org/wiki/Special:AbuseFilter/304 ) and I saw no hCaptcha challenge.

Checked on test wiki, it does not happen anymore

Close as all the config variable depends on the title

Seems fixed on wiki 1.46.0-wmf.26

Will test again tomorrow Apr 28th 2026,

The fix for this variable in mediawiki-config was merged on Mar 17th, but probably deployed on Tuesday 24th of March.

I can reproduce this locally if I put $wgHCaptchaEnabledInMobileFrontend = false; in my LocalSettings.php.

I've tested this locally on latest master of ConfirmEdit.
As an admin -> edit -> visual editor -> source editor -> try to trigger AbuseFilter -> saves with no hCaptcha.

Thanks, moved to QA.

Hi @OKryva-WMF,
could you please approve this request?
Thank you

In T421071#11743624, @Dreamy_Jazz wrote:

The existing linter configuration (inherited from mediawiki-codesniffer) sets a soft warning at 120 characters but no hard error

mediawiki-codesniffer in PHP sets 120 chars as a hard limit, which you have to specifically ignore because otherwise the tests will fail in CI and prevent merging. Is this not PHP you are talking about?

I confirm I'll consult with the DBA

Thank you,
I've joined the ops-l mailing list and asked access for spiderpig