Page MenuHomePhabricator

Special:AbuseLog uses `mw-anonuserlink` for unattached accounts
Open, LowestPublicBUG REPORT

Description

Sadly I can't find a public page where this happens, and I can't demonstrate on testwiki without setting a filter to disallow account creation, but if you're able to view private filters on enwiki, please see https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=54. To highlight the mw-anonuserlink instances, add the following to your common.css

.mw-anonuserlink {
	background-color: pink;
}

Otherwise, you can inspect the HTML to verify.

What happens?:

Unattached accounts (which are possible here because the filter prevents them from attaching) are given the class mw-anonuserlink. This can cause issues for any CSS changes that assume that mw-anonuseflink will only ever be used for anonymous users. For instance, I use my common.css to lowercase all mw-anonuserlinks to make IPv6 addresses a bit less obtrusive in my watchlist.

What should have happened instead?:

Either the standard mw-userlink or some third option should have been used.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

Google Chrome on Windows 10, Version 94.0.4606.81 (Official Build) (64-bit)

My guess is that this would happen on any special page; it's just that the AbuseLog is (to my knowledge) the only place where an unattached account can be listed as the actor for a logged action.

Event Timeline

Tamzin triaged this task as Lowest priority.Oct 14 2021, 12:11 AM
Tamzin updated the task description. (Show Details)

My guess is that this would happen on any special page; it's just that the AbuseLog is (to my knowledge) the only place where an unattached account can be listed as the actor for a logged action.

I think that is correct. AbuseFilter uses core's Linker::userLink, which always adds the mw-anonuserlink class when there's no user ID.

@Daimona I found it in one other place. For whatever reason, there are a few blocks in Special:BlockList on enwiki logged against nonexistent users. (Not sure if that needs to be a bug of its own, or already is one.) This same thing happens there. See e.g. James5smith and SLR Consulting Ltd @ this BlockList query.

mw-anonuserlink means the user name is not a registered user on that wiki. This also happens for imported user. The code links T45179 for the separate class, but anon != ip in mediawiki (User::isAnon also checks for registered users, not for ip addresses).

This maybe not what the user expect, so this needs another class for ips. When doing this also think about ip ranges