Page MenuHomePhabricator

Special:AbuseLog uses `mw-anonuserlink` for unattached accounts
Closed, ResolvedPublicBUG 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

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.

While I also think this is correct, AbuseLog currently does not check whether a given account has been created/merged after the filter was triggered. For example:

Capture.PNG (1,235×115 px, 34 KB)

Both log entries in the screenshot triggered the Disallow action, so the accounts didn't exist at the time of the trigger. But on this server TestUser4 has already been merged locally, whereas TestUser5 hasn't. For both these accounts the user link has the mw-anonuserlink class.
AFAICT this interface could be improved in the following ways:

  • For TestUser5, the user link having the mw-anonuserlink class is correct since the account doesn't exist locally, but the block link shouldn't be generated because the account can't be blocked.
  • For TestUser4, the user link shouldn't have the mw-anonuserlink class because the account has already been created locally.

So, something like the following would be ideal:

Capture (1).PNG (1,231×118 px, 35 KB)

Dragoniez raised the priority of this task from Lowest to Needs Triage.

Change #1237252 had a related patch set uploaded (by Dragoniez; author: Dragoniez):

[mediawiki/extensions/AbuseFilter@master] Improve Special:AbuseLog's rendering of user links for unattached accounts

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

Change #1237252 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Improve Special:AbuseLog's rendering of user links for unattached accounts

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

Unattached accounts on AbuseLog for account creation attempts will be styled with a dotted underline thanks to a newly introduced class attribute, mw-abusefilter-log-missinguserlink. Note that these links may still have the mw-anonuserlink class unless they are for temporary users, but they will now be styled by the backend, making it likely unnecessary for frontend users to prepare their own stylesheets.