Ok so I did some testing. Expected behaviour is that the user only needs to enter the captcha once and acknowledge the warning once.

What actually happens is the user is asked to enter a captcha, enters it correctly and clicks save, gets the warning with no captcha present, then is asked to enter a 2nd captcha, and then clicking save will save the edit.

@Etonkovidova Can you please check this bug also affecting VisualEditor along with CX?

Checking in betalabs - @Samwalton9 described the current behavior correctly:

[...] the user is asked to enter a captcha, enters it correctly and clicks save, gets the warning with no captcha present, then is asked to enter a 2nd captcha, and then clicking save will save the edit.

The steps in betalabs may be as following:

• a new user (belonging to Users group only), logs in and makes an action that triggers one of the Abuse filters - e.g. blank the page
• on the blanked page a user enters an external link to trigger Captcha.
• Click 'Publish' - when the captcha will be present, enter it and click 'Publish' again
• Another captcha will be present (no warning if you entered the previous captcha incorrectly). After entering the captcha second time, the edits are saved and AbuseLog will correctly record that the edit triggered one of the Abuse filters.

Specific to CX
@KartikMistry
(1) it seems that I cannot pass the captcha in CX (cx2-testing) with Abuse filter #1 (Youtube links) - which has 'Disallow' action . Attempting to publish a translated article with the text "trigger Abuse filter www.youtube.com", will make the captcha appear again and again. 'Disallow' warning never appears.

(2) Publishing an article that has only warning action Abuse filter #12 (Word filter with the text "Hello World,") is possible with two captchas appear as it described in the ticket and my steps above.

(3) Abuse Log records too many entries for hitting Abuse filter ( e.g. Special:AbuseLog for User: ET1) - something that's probably worth investigating.

(4) It'd be great to have the exact specs on how the Abuse filters warnings should work in CX (is there a phab task already?) and to address the long-standing issue of two captchas.

This was previously reported as T22661, and later as T179789.

Marking as "watching" since this does not appear to require work by Platform Engineering . Rather it is interaction between AbuseFilter and ConfirmEdit (CAPTCHA extension).

What actually happens is the user is asked to enter a captcha, enters it correctly and clicks save, gets the warning with no captcha present, then is asked to enter a 2nd captcha, and then clicking save will save the edit.

Only if ConfirmEdit is loaded before AbuseFilter (as is done on WMF wikis). I tried reversing the order on a local wiki, and could reproduce the original problem described here: At least in the 2010 editor, I was just bounced back and forth with no way to save the edit.

I think this is no longer an issue, but moving to TSP's QA to confirm.

I have been banging my head against this for a while. All I can say for now is that there are circumstances where this bug can be reproduced (or something like it).

For example, if you trigger a filter which has both the captcha and warning consequences you will bounce between the warning page and the captcha page. Note that if ConfirmEdit is enabled, this won't happen, however you will have to enter the captcha twice (once when first submitting the edit, once after seeing the warning).

Perhaps not strictly part of this task, but I can reproduce an endless loop of warnings as well. Make an edit which triggers one filter with a warning. Then modify your edit to trigger a second filter which also shows a warning. You are bounced back and forth between the two warnings.

The number of different factors that affect the behaviour here is too many to test effectively:

• Abuse Filters can have any combination of 7 consequences (127 combinations in total) (8 if you include degroup which I see in the code but it isn't on my wiki)
• Need to test global filters as well as local?
• Multiple filters can be triggered at once
• Different filters can be triggered in a chain (like the warning bug described above)
• We need to test with and without ConfirmEdit enabled? If T151116#9802313 is true, I will cry (I could not reproduce thankfully, but I didn't test for very long).
• Test all the above but this time getting the captcha wrong
• Do we need to test each editor (I know that the API and 2010 Wikitech editors behave differently)?

AbuseFilter doesn't have anything like an API or CLI which could help test these combinations. I tried doing it via unit testing but I could not get captchas to work. Even if I did, that doesn't test that the editors are handling what the get from AbuseFilter correctly. I had to do so first via the API and then (when I realised that behaves differently to the wikitext editor) by POST HTTP requests and parsing the response. This has left me with a huge amount of data which I am unsure how to analyse.

Also, triggering a filter with both the blockautopromote and disallow consequences will not trigger the disallow and will instead allow the user to successfully edit. I don't know if this is a known bug.

In T151116#10196141, @dom_walden wrote:

...by POST HTTP requests and parsing the response. This has left me with a huge amount of data which I am unsure how to analyse.

I have worked more on this and I think I have a reasonable solution. What I say above still applies and I would approach these results with some skepticism.

I tested randomly triggering multiple different filters in a chain while editing and recording the response. I then checked that I was getting the appropriate response depending on which filters I triggered when submitting the editing form.

I tested local and global filters. I also tested with ConfirmEdit enabled. I only tested editing.

As well as I what I mention above (which I repeat below for clarity) I found a few issues but nothing major.

If I trigger a filter with both disallow and warn consequences I will be bounced back and forth between the disallow and the warn error message. This might be bad user experience but at least they should be prevented from performing the action in this circumstance.

If I trigger a captcha for one filter and, on resubmitting the form, I enter the correct captcha but trigger a different filter with a captcha consequence, the edit will go through (unless it also has a block or disallow consequence). Should I instead be taken back to the edit form to fill out a second captcha?

In T151116#10196141, @dom_walden wrote:

For example, if you trigger a filter which has both the captcha and warning consequences you will bounce between the warning page and the captcha page. Note that if ConfirmEdit is enabled, this won't happen, however you will have to enter the captcha twice (once when first submitting the edit, once after seeing the warning).

Perhaps not strictly part of this task, but I can reproduce an endless loop of warnings as well. Make an edit which triggers one filter with a warning. Then modify your edit to trigger a second filter which also shows a warning. You are bounced back and forth between the two warnings.

I also raised T377579.