Also: https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchFilter=224&wpSearchTitle=M.R.+Organisation+Limited

(Adding 'hhvm' keyword just in case it's related to that.)

Here is another example on Portuguese Wikipedia:
https://pt.wikipedia.org/wiki/Special:AbuseFilter/examine/log/1898713?uselang=en
https://pt.wikipedia.org/w/index.php?diff=40613438&uselang=en
The string "{{ESR2|" is in "removed_lines" but not in "added_lines". However, it should not be in the "removed_lines", because it is still in the new revision:
https://pt.wikipedia.org/w/index.php?title=Zats_Boy&action=edit&oldid=40613438

This was reported on
https://pt.wikipedia.org/wiki/WP:CP?oldid=40613984#Falso_positivo_na_etiqueta

I found how to reproduce this bug, at least in some cases. If you edit a page with VisualEditor and an automatic merge happens when you submit (i.e. someone submits a change between the moment you click "edit" and the moment you press "submit"), then AbuseFilter sees the revision before the merge.

readding VisualEditor: was removed without explanation and the correlation seems obvious.

@Oriodrim: Yep, I guessed the same in the linked dupe, AbuseFilter seems to see the pre-automerged version of edits from VisualEditor.

I have found the cause: The problem is that edits through API (that is the difference, @Catrope re your comment) pass through the AbuseFilter twice: The first time, via the onAPIEditBeforeSave hook, the second time via the onEditFilterMergedContent hook. Only the second hooks gets the post-merged content.

And, because AbuseFilter makes sure it processes every edit only once, it sets editAlreadyFiltered in filterEdit and on every subsequent hook call for the same edit it just returns without further processing. It means AbuseFilter sees and processes the pre-merged content in onAPIEditBeforeSave, and ignores the post-merged content in onEditFilterMergedContent.

You could check this by adding unset($context->getTitle()->editAlreadyFiltered); at the end of onAPIEditBeforeSave – the filter will run correctly the second time and see the postmerged content, however, the edit will be noted twice in the abuse log, so this is (obviously) not a correct solution.

I’d think the correct solution would be to make a variant of APIEditBeforeSave hook which would include the post-merged text and AbuseFilter would then switch to that new hook. Maybe. (Or, some voodoo with making sure APIEditBeforeSave is read-only, immutable test-this-edit, saving nothing into the abuse log, and not setting the editAlreadyFiltered flag. But that could be a bit brittle, I guess.)

@He7d3r This bug is the cause of the problem related in T100530, right?

As far as I can see, they are the same thing;

@He7d3r Hunm, well. At least the cause of this bug was identified, but the solutin does not seem to be simple...

This came up on the English Wikipedia again this week. Any chance of a fix? It seems like a pretty big issue that we are sometimes tagging and disallowing entirely the wrong edits.

https://en.wikipedia.org/wiki/WP:Village_pump_%28technical%29?oldid=694005525#Edit_filter_problem

Any chance of a fix?

Any contributed patches are welcome to speed up progress here.
See https://www.mediawiki.org/wiki/Developer_access and https://www.mediawiki.org/wiki/Gerrit/Tutorial for more information.

Change 282100 had a related patch set uploaded (by Bartosz Dziewoński):
Avoid crippled APIEditBeforeSave hook, use new features of EditFilterMergedContent instead

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

This proved easier to fix than I expected thanks to @tstarling's wonderful work in 09a5febb7b024c0b6585141bb05cba13a642f3eb.

Change 282100 merged by jenkins-bot:
Avoid crippled APIEditBeforeSave hook, use new features of EditFilterMergedContent instead

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