In T392756#10770315, @Alien333 wrote:

I think this is due to the <input type="hidden" name="title" value="Username"> right after the button.

Due to this part of your code: https://github.com/Nevallem/mw-gadget-requestForAdminship/blob/main/src/core.js#L429.

By input[name="title"], you probably meant to select one of the two fields at https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Administradores/Pedidos_de_aprova%C3%A7%C3%A3o. But there are also hidden inputs that the search button uses.

So get a better, more specific selector.

Also keep in mind: selecting elements with [prop=abc] is a bad idea, precisely due to risks like this. Use a class, or better yet, an ID, that's sure to not be ambiguous.

In T304095#7791583, @Urbanecm_WMF wrote:

In T304095#7791123, @Silent wrote:

I think this change should solve the problem.

Indeed, thank you for changing the filter.

Would it be possible for you to exempt Add a link edits from the filter as well (by adding growthexperiments-addlink-summary-summary)? Add a link is not deployed at pt.wikipedia as of today, but we'd like to have it allowed by the filter regardless, as if/once deployed, they'd face the same problem. Doing it now will help us avoid the same issue re-occuring in the future.

I think this change should solve the problem.

Some prevision to solve this task?

In T176291#4843352, @Daimona wrote:

@He7d3r Yeah, I'm well aware of the problem, I also constantly face it when I need to examine AbuseLog entries in order to tune filters. The patch above would fix the problem, but unfortunately it's not optimal - actually, it's pretty hacky. A nicer solution will need more thought, but I'll hopefully get on it after holidays.

What happened with the chars "ÁÀÂÃ@ê" etc? They were already being normalized, so i remove from the filters on ptwiki. Now, they back to be unnormalized again and things like "FILHA DA PUT@ DE QUATRO" (son of a bitch [...]) passed...

Some news of this task? That problem is very complicated in ptwiki, that makes the filters very complex.
Besides, the normalization of the character "|" difficults further.

I don't suggest € -> G. I put ĘĒĔĖĚ€ = EEEEEE and ĜĢ = GG.

More chars to the list:

I identified that this problem occours when the IPv6 is in lowercase, like "2804:7f3:85:df17:f0b1:fc6c:8772:8cb0". When they are in uppercase, like "2804:7F3:85:DF17:F0B1:FC6C:8772:8CB0", works fine.

Yes, this occurs with all filters. The problem is with the field "wpTestUser" which don't leads very well with IPv6.

I'm sorry, i don't explained very well.
The problem is with the field "wpTestUser" in Special:AbuseFilter/test. Put a IPv6 into this field, generally, return zero response, even when the IPv6 had a edit recently. With IPv4 this not occurs. With a IPv6 only works always if you place the prefix "User:" berfore, like "User:2804:1b1:2103:7689:f8a1:22cb:4add:87f5". This was the problem which i was trying describes.

Isn't a big problem turn that filter in public, so i did. You already can see the code now.

Mean which don't appears in "Action parameters" table. That table in abuse filter logs page that shows the variables and the respective values.