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.