Suggested text for user notice:

AbuseFilter can show a CAPTCHA to a user before they can proceed with an action. Not all actions may be supported, but the CAPTCHA action should work well for source and API edits. As this is a new action, please use with caution and report any issues as subtasks of T20110.

Thanks for implementing this! But I'm having trouble getting it to work on testwiki. This edit from an account without skipcaptcha rights tripped a showcaptcha filter, but did not require a CAPTCHA.

In T20110#9796395, @suffusion_of_yellow wrote:

Thanks for implementing this! But I'm having trouble getting it to work on testwiki. This edit from an account without skipcaptcha rights tripped a showcaptcha filter, but did not require a CAPTCHA.

Thanks for testing, and reporting the issue, I'm not sure why it's occurring. Looking into it...

In T20110#9796476, @kostajh wrote:

In T20110#9796395, @suffusion_of_yellow wrote:

Thanks for implementing this! But I'm having trouble getting it to work on testwiki. This edit from an account without skipcaptcha rights tripped a showcaptcha filter, but did not require a CAPTCHA.

Thanks for testing, and reporting the issue, I'm not sure why it's occurring. Looking into it...

Looking at debug logs for an edit that triggers this filter, we end up at "ConfirmEdit: no need to show captcha.". Looking at the relevant function in the XHGui output I can see that onConfirmEditTriggersCaptcha is invoked. Looking at the hook implementation for ConfirmEditTriggersCaptcha I can see that the AbuseFilter hook runs. So one possibility is that that setting the CaptchaConsequence on the WebRequest object in the RequestContext in one hook didn't persist when reading it back in the other hook.

Hey, noticed on testwiki that some of you are trying this from your main account; that probably has skipcaptcha rights so will never be shown one.

FWIW, I have also tried this on your patch demo, and also get no captcha. Also tried on a local wiki, and again get no captcha. I even tried loading AbuseFilter before ConfirmEdit (a bad idea, breaks the "throttle" filters and also causes T151116), and still no luck.

Change #1031549 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] CaptchaConsequence: Use SessionManager to communicate with AbuseFilter

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

Change #1031550 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use Session instead of WebRequest

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

In T20110#9796913, @suffusion_of_yellow wrote:

Hey, noticed on testwiki that some of you are trying this from your main account; that probably has skipcaptcha rights so will never be shown one.

Yeah, I realized that and switched to using a logged out user for the test. Thanks for flagging though, it's easy to forget about that!

FWIW, I have also tried this on your patch demo, and also get no captcha. Also tried on a local wiki, and again get no captcha. I even tried loading AbuseFilter before ConfirmEdit (a bad idea, breaks the "throttle" filters and also causes T151116), and still no luck.

Thanks for that. I've uploaded an alternative approach that I think would be more robust.

In T20110#9797066, @kostajh wrote:

Thanks for that. I've uploaded an alternative approach that I think would be more robust.

Tried that on my local wiki (all edits made logged out):

• Loading ConfirmEdit before AbuseFilter (the same order as WMF wikis), I get no captcha on the first attempted edit. I do get a CAPTCHA, the next time I open a page for editing, even before I try to publish.
• Loading AbuseFilter before ConfirmEdit, I get a "Incorrect or missing CAPTCHA. " error (even though I would have had no idea a CAPTCHA was to be expected). Also, the message is at the top, but the CAPTCHA entry form is at the bottom. But reversing the order would be a very bad idea; it would cause "throttle" filters to trip on innocent users struggling with the CAPTCHA, and also prevent any user from adding an external link, if they also trip a "warn" filter.

In T20110#9797176, @suffusion_of_yellow wrote:

In T20110#9797066, @kostajh wrote:

Thanks for that. I've uploaded an alternative approach that I think would be more robust.

Tried that on my local wiki (all edits made logged out):

• Loading ConfirmEdit before AbuseFilter (the same order as WMF wikis), I get no captcha on the first attempted edit. I do get a CAPTCHA, the next time I open a page for editing, even before I try to publish.
• Loading AbuseFilter before ConfirmEdit, I get a "Incorrect or missing CAPTCHA. " error (even though I would have had no idea a CAPTCHA was to be expected). Also, the message is at the top, but the CAPTCHA entry form is at the bottom. But reversing the order would be a very bad idea; it would cause "throttle" filters to trip on innocent users struggling with the CAPTCHA, and also prevent any user from adding an external link, if they also trip a "warn" filter.

Aha. Yeah, I am loading AbuseFilter before ConfirmEdit in my local wiki. Thank you for testing the patches and leaving the detailed notes. OK, I'll look at this more closely tomorrow.

Alternatively, would it be possible to set a static flag in one of the ConfirmEdit classes? In theory, it doesn't even need to be static as long as the class in question is obtained through the service container. Something like AbuseFilter's own EditRevUpdater::$logIds. Another thing is that this could live all within the ConfirmEdit extension, and the property might be read in triggersCaptcha directly, without using a hook.

Won't ConfirmEdit need to be run twice, though? Once before AbuseFilter, to avoid filter trips from repeated bad CAPTCHAs, then again after AbuseFilter iff (A) No CAPTCHA was show on the first run, and (B) A showcaptcha filter was tripped.

Yeah, just to clarify, my comment was only in response to the switch from WebRequest to Session. But indeed, it does not address the bug above, which seems to be due to the order of execution.

FWIW, I have also tried this on your patch demo, and also get no captcha.

Correction. I didn't realize that the "Type 'patchdemo' here as an anti-spam measure." box was coming from QuestyCaptcha, and thought it was some generic anti-spam measure on all patchdemos.

So what actually happened is that I did get a request for a CAPTCHA, but the box was there before I even tried to click "Publish"! This cannot be coming from AbuseFilter; the filters haven't even been checked yet. Do you have ConfirmEdit enabled for all edits with something like $wgCaptchaTriggers['edit'] = true;?

In T20110#9791865, @kostajh wrote:

Suggested text for user notice:

AbuseFilter can show a CAPTCHA to a user before they can proceed with an action. Not all actions may be supported, but the CAPTCHA action should work well for source and API edits. As this is a new action, please use with caution and report any issues as subtasks of T20110.

The user notice should wait, because the functionality isn't working yet in production.

Change #1031757 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] AbuseFilterHooks: Provide feature flags for AF custom actions

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

Change #1031550 abandoned by Kosta Harlan:

[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use Session instead of WebRequest

Reason:

Doesn't fix the underlying issue, which is due to order of extension loading in production.

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

Change #1031549 abandoned by Kosta Harlan:

[mediawiki/extensions/ConfirmEdit@master] CaptchaConsequence: Use SessionManager to communicate with AbuseFilter

Reason:

Doesn't fix the underlying issue, which is due to order of extension loading in production.

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

You could reorder the list of extensions to be loaded in production, it has been done before for the exact same problem but 1- It's not sustainable 2- it might break other things.

In T20110#9798669, @Ladsgroup wrote:

You could reorder the list of extensions to be loaded in production, it has been done before for the exact same problem but 1- It's not sustainable 2- it might break other things.

It will break other things.

I’m working on a patch that uses a different approach, will clean it up and push for review later today.

Change #1031885 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] [WIP] SimpleCaptcha: Allow invoking from other extensions

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

Change #1031886 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/AbuseFilter@master] [WIP] ConfirmEditHandler: Use SimpleCaptcha to invoke CAPTCHA display

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

Change #1031921 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@wmf/1.43.0-wmf.5] AbuseFilterHooks: Provide feature flags for AF custom actions

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

Change #1031757 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] AbuseFilterHooks: Provide feature flags for AF custom actions

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

Change #1031921 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@wmf/1.43.0-wmf.5] AbuseFilterHooks: Provide feature flags for AF custom actions

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

Mentioned in SAL (#wikimedia-operations) [2024-05-15T20:59:39Z] <samtar@deploy1002> Started scap: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (T20110)]]

Mentioned in SAL (#wikimedia-operations) [2024-05-15T21:02:20Z] <samtar@deploy1002> samtar and kharlan: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (T20110)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-05-15T21:16:10Z] <samtar@deploy1002> Finished scap: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (T20110)]] (duration: 16m 31s)

In T20110#9797662, @suffusion_of_yellow wrote:

FWIW, I have also tried this on your patch demo, and also get no captcha.

Correction. I didn't realize that the "Type 'patchdemo' here as an anti-spam measure." box was coming from QuestyCaptcha, and thought it was some generic anti-spam measure on all patchdemos.

So what actually happened is that I did get a request for a CAPTCHA, but the box was there before I even tried to click "Publish"! This cannot be coming from AbuseFilter; the filters haven't even been checked yet. Do you have ConfirmEdit enabled for all edits with something like $wgCaptchaTriggers['edit'] = true;?

@suffusion_of_yellow Yeah, Patch Demo isn't a good environment for verifying these patches because it sets a CAPTCHA for all edits for not logged-in users, and gives all logged-in users skipcaptcha right. We'd need to make some adjustments. The config it uses (extensions-ConfirmEdit.php):

$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['createaccount'] = true;
// Don't show CAPTCHA when logged in
$wgGroupPermissions['user']['skipcaptcha'] = true;

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031885 https://gerrit.wikimedia.org/r/c/1031886

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031885 https://gerrit.wikimedia.org/r/c/1031886

Tried these patches. I am using the 2010 editor, and these options:

wfLoadExtensions( ['ConfirmEdit', 'ConfirmEdit/QuestyCaptcha'] );
$wgCaptchaQuestions = [
    'What is the answer to Life, the Universe, and Everything?' => '42'
];
$wgConfirmEditEnabledAbuseFilterCustomActions = [ 'showcaptcha' ];
                                                                                
wfLoadExtension( 'AbuseFilter' );

First, I set a filter to "showcaptcha", and attempted an edit NOT adding external links. After clicking "publish" the first time, at the top of the page, I got the message "Incorrect or missing CAPTCHA." even though I was never asked for one in the first place. The actual CAPCTHA was at the bottom of the page. The page saved successfully when I answered correctly.

Second, I attempted an edit adding external links, keeping the filter set to "showcaptcha". This time, I got the standard "Your edit includes new external links..." message, and the captcha input was at the top, right below the message. (This is the expected behavior.)

Third, I set a filter to "warn" and "showcaptcha", and attempted an edit NOT adding external links. This time, I was bounced back and forth endlessly between the warning message and the request for a CAPTCHA. There was no way to save the page.

Fourth, I attempted an edit adding external links, keeping the filter set to "warn" and "showcaptcha". This time I got one request for a CAPTCHA, then the warning, then a second request, but the edit finally saved. (This is not optimal, but AFAIK an existing problem not caused by this patch.)

So three improvements are needed here:

• The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.
• The CAPTCHA input should be at the top, near the message (same as when adding external links)
• There should be some way to save a page when a filter is set to warn+showcaptcha (other than adding a new link), or this option should be forbidden when saving a filter.

In T20110#9901516, @suffusion_of_yellow wrote:

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031885 https://gerrit.wikimedia.org/r/c/1031886

Tried these patches. I am using the 2010 editor, and these options:

wfLoadExtensions( ['ConfirmEdit', 'ConfirmEdit/QuestyCaptcha'] );
$wgCaptchaQuestions = [
    'What is the answer to Life, the Universe, and Everything?' => '42'
];
$wgConfirmEditEnabledAbuseFilterCustomActions = [ 'showcaptcha' ];
                                                                                
wfLoadExtension( 'AbuseFilter' );

First, I set a filter to "showcaptcha", and attempted an edit NOT adding external links. After clicking "publish" the first time, at the top of the page, I got the message "Incorrect or missing CAPTCHA." even though I was never asked for one in the first place. The actual CAPCTHA was at the bottom of the page. The page saved successfully when I answered correctly.

Second, I attempted an edit adding external links, keeping the filter set to "showcaptcha". This time, I got the standard "Your edit includes new external links..." message, and the captcha input was at the top, right below the message. (This is the expected behavior.)

Third, I set a filter to "warn" and "showcaptcha", and attempted an edit NOT adding external links. This time, I was bounced back and forth endlessly between the warning message and the request for a CAPTCHA. There was no way to save the page.

Fourth, I attempted an edit adding external links, keeping the filter set to "warn" and "showcaptcha". This time I got one request for a CAPTCHA, then the warning, then a second request, but the edit finally saved. (This is not optimal, but AFAIK an existing problem not caused by this patch.)

Thanks so much for testing and for the detailed notes!

So three improvements are needed here:

• The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.

I think this should be possible without too many hacks.

• The CAPTCHA input should be at the top, near the message (same as when adding external links)

This one, I am not sure about yet. Maybe we could do that in a follow-up task?

• There should be some way to save a page when a filter is set to warn+showcaptcha (other than adding a new link), or this option should be forbidden when saving a filter.

I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.

In T20110#9925563, @kostajh wrote:

In T20110#9901516, @suffusion_of_yellow wrote:

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031885 https://gerrit.wikimedia.org/r/c/1031886

Tried these patches. I am using the 2010 editor, and these options:

wfLoadExtensions( ['ConfirmEdit', 'ConfirmEdit/QuestyCaptcha'] );
$wgCaptchaQuestions = [
    'What is the answer to Life, the Universe, and Everything?' => '42'
];
$wgConfirmEditEnabledAbuseFilterCustomActions = [ 'showcaptcha' ];
                                                                                
wfLoadExtension( 'AbuseFilter' );

First, I set a filter to "showcaptcha", and attempted an edit NOT adding external links. After clicking "publish" the first time, at the top of the page, I got the message "Incorrect or missing CAPTCHA." even though I was never asked for one in the first place. The actual CAPCTHA was at the bottom of the page. The page saved successfully when I answered correctly.

Second, I attempted an edit adding external links, keeping the filter set to "showcaptcha". This time, I got the standard "Your edit includes new external links..." message, and the captcha input was at the top, right below the message. (This is the expected behavior.)

Third, I set a filter to "warn" and "showcaptcha", and attempted an edit NOT adding external links. This time, I was bounced back and forth endlessly between the warning message and the request for a CAPTCHA. There was no way to save the page.

Fourth, I attempted an edit adding external links, keeping the filter set to "warn" and "showcaptcha". This time I got one request for a CAPTCHA, then the warning, then a second request, but the edit finally saved. (This is not optimal, but AFAIK an existing problem not caused by this patch.)

Thanks so much for testing and for the detailed notes!

So three improvements are needed here:

• The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.

I think this should be possible without too many hacks.

• The CAPTCHA input should be at the top, near the message (same as when adding external links)

This one, I am not sure about yet. Maybe we could do that in a follow-up task?

• There should be some way to save a page when a filter is set to warn+showcaptcha (other than adding a new link), or this option should be forbidden when saving a filter.

I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.

@Dreamy_Jazz has +2'ed the patches and one of us will make follow up patches for these issues. The feature is behind a config flag so there is not a risk of this being in front of users.

Change #1031886 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use SimpleCaptcha API to invoke CAPTCHA display

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

Change #1031885 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Allow invoking CAPTCHA display from other extensions

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

I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.

FWIW, I tried setting one filter to "warn", and another to "showcaptcha", and it worked! I got both the warning and the CAPTCHA form on the same page, and after filling in the CAPTCHA, I was able to save the page. Not sure why it doesn't work when both settings are on the same filter; maybe it's just a minor bug?

In T20110#9936300, @suffusion_of_yellow wrote:

I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.

FWIW, I tried setting one filter to "warn", and another to "showcaptcha", and it worked! I got both the warning and the CAPTCHA form on the same page, and after filling in the CAPTCHA, I was able to save the page. Not sure why it doesn't work when both settings are on the same filter; maybe it's just a minor bug?

Ah, cool, good to know. Thanks.

Change #1052909 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set

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

Change #1053238 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis

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

Change #1053238 merged by jenkins-bot:

[operations/mediawiki-config@master] ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis

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

Mentioned in SAL (#wikimedia-operations) [2024-07-10T07:57:08Z] <kharlan@deploy1002> Started scap sync-world: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (T20110)]]

Mentioned in SAL (#wikimedia-operations) [2024-07-10T07:59:50Z] <kharlan@deploy1002> kharlan: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (T20110)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-07-10T08:06:49Z] <kharlan@deploy1002> Finished scap: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (T20110)]] (duration: 09m 41s)

Change #1052909 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set

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

In T20110#9901516, @suffusion_of_yellow wrote:

• The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.

That is done in SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set. Although, it's worth noting that VisualEditor and DiscussionTools do not update their CAPTCHA message on failure (not related to this implementation) as far as I can tell. But for source editor, you'll get an updated message after failing to submit an edit.

The showcaptcha AbuseFilter consequence is now available on testwiki and beta cluster wikis.

For QA, it would be helpful to test out:

• Adding a showcaptcha consequence
• Triggering that consequence through API edits (VisualEditor, DiscussionTools) and non-API edits

The intention for this consequence is to be used in an editing context, but would be helpful to know how well it works / doesn't work in other situations (account creations, page moves, etc).

It could also be helpful to understand how the throttled notifications issue works out as discussed in T303433#10017793, but that could be QA'ed separately, if there isn't time to look at it here.

Change #1056146 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere

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

In T20110#10006557, @kostajh wrote:

• Triggering that consequence through API edits (VisualEditor, DiscussionTools) and non-API edits

I have seen the captcha for source editor, VE and DiscussionTools, and successfully edited after completing the captcha.

Editing via the API I get a response:

{
    "edit": {
        "captcha": {
            "type": "image",
            "mime": "image/png",
            "id": "218847720",
            "url": "/w/index.php?title=Spezial:Captcha/image&wpCaptchaId=218847720"
        },
        "result": "Failure"
    }
}

The intention for this consequence is to be used in an editing context, but would be helpful to know how well it works / doesn't work in other situations (account creations, page moves, etc).

createaccount

Testing a filter with action=="createaccount".

I could not get the captcha to work for the createaccount action on beta. Perhaps this is because IP and newly created users already see a captcha when trying to create an account.

Locally, I had to set $wgCaptchaTriggers['createaccount'] = false; in order to see the AF captcha consequence after trying to submit Special:CreateAccount. However, even after completing the captcha and re-submitting it does not succeed and continues to show the error Incorrect or missing CAPTCHA.

autocreateaccount

Filter with action=="autocreateaccount".

Testing on dewiki beta, I do see the captcha after attempting to submit the edit. However, the temporary account has already been created at this point.

move

I could not get this to work for the move action. On beta, IP and newly created users cannot move articles. I had to test this locally and give all users move rights.

I did not test other actions like upload or delete.

Other observations

I could not get this to work for a global filter (testing on https://meta.wikimedia.beta.wmflabs.org). EDIT: I cannot get global filters to work at all, either on beta or locally.

Change #1056146 merged by jenkins-bot:

[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere

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

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.

[see https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.

Also, it's worth noting that this action is NOT a restricted action per https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard#c-Xaosflux-20240807193100-Codename_Noreste-20240807172500 on the edit filter noticeboard on enwiki.

In T20110#10048229, @XXBlackburnXx wrote:

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.

I can reproduce on VE. For Source Editor, I can only reproduce if I have a single AB rule which triggers both a warning and a captcha.

I wonder if it is the same bug as T151116. @kostajh?

In T20110#10049437, @codenamenoreste wrote:

[see https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.

@codenamenoreste Does the user have the skipcaptcha right? This is assigned to autoconfirmed users, for example.

In T20110#10069310, @dom_walden wrote:

In T20110#10048229, @XXBlackburnXx wrote:

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.

I can reproduce on VE. For Source Editor, I can only reproduce if I have a single AB rule which triggers both a warning and a captcha.

I wonder if it is the same bug as T151116. @kostajh?

I will do more testing of multiple/conflicting abuse filters when we implement T372642. I will move this along.

In T20110#10049437, @codenamenoreste wrote:

[see https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.

@codenamenoreste Does the user have the skipcaptcha right? This is assigned to autoconfirmed users, for example.

I could have just checked this myself. The user is in the group "autoconfirmed users" which does have the skipcaptcha right.

I assume that is the reason they did not see the captcha.