Page MenuHomePhabricator

Special:Contributions shows contribs when passed User:Foo, and also say "user does not exist"
Closed, ResolvedPublic

Description

URLs like https://en.wikipedia.org/wiki/Special:Contributions/User:Tks4Fish look like this:

image.png (561×1 px, 108 KB)

That is incorrect, either it should automatically strip the User: prefix (and ideally redirect to the canonical page, https://en.wikipedia.org/wiki/Special:Contributions/Tks4Fish), or it should literally look for user called "User:Tks4Fish" (which indeed doesn't exist).

I suspect recent CPT refactoring might be related, tagging the team as well.

Related Objects

Event Timeline

For the subtitle links and the error message, the provided request parameter is used without strict validation because validation of the username (which will lead to normalizing such names) is not desirable because of IP usernames. The contributions query uses user_id not username, that's why a successful result is returned and displayed.

Change 697145 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] SpecialContributions: Normalize user provided username

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

Change 697145 merged by jenkins-bot:

[mediawiki/core@master] UserNameUtils: Always strip subject namespace in canonical username.

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

The patch does it the wrong way. It is better to convert the namespace text to namespace number and then match against NS_USER to take alias into account (and possible gender aliases).
The patch currently gets the namespace text for the namespace number NS_USER and checks if it starts with it.

https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Beitr%C3%A4ge/Benutzer:Umherirrender works (no warnbox, but header still shows the namespace), it is using the content language (de) form of NS_USER, while
https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Beitr%C3%A4ge/User:Umherirrender does not work (it shows the warnbox)

It would also break with all the other title normalization like whitespaces, underscores, case-insensitive of namespaces. The lookup text => constant typically ignore all of this parts (Language::getNsIndex).

https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Beitr%C3%A4ge/Benutzer:Umherirrender works (no warnbox, but header still shows the namespace), it is using the content language (de) form of NS_USER, while

The header is based on the bad URL, while it's good to fix, it doesn't seem essential to me here. The URL will anyway remain the way it is. It should be redirected to the canonical form and the header will then automatically update.

https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Beitr%C3%A4ge/User:Umherirrender does not work (it shows the warnbox)

Why will someone do that? (the interface will not output such links). Even on English Wikipedia User:User:User:Foo will not work because only the first prefix is stripped, but since this is garbage, it seems appropriate to return in kind.

It would also break with all the other title normalization like whitespaces

No, as Language itself does not do that always. Even if we use nsIndex, Language::getNsIndex("User ") is always false.

...underscores, case-insensitive of namespaces. The lookup text => constant typically ignore all of this parts (Language::getNsIndex).

Underscores are always removed, maybe case-insensitiveness can be supported, but same as above. It's not very common.

I don't think it's a good idea to redo all these normalizations again in UsernameUtils. To 'completely' fix this would require duplicating MediaWikiTitleCodec code or moving the namespace stripping logic to a separate function that we can invoke it without full parsing to fully remove them recursively, but I would consider that for low-prio enhancement, as the most common case reported here is fixed, repeated namespace is garbage, non-content language namespace is not common.

I am not sure what

Even on English Wikipedia User:User:User:Foo will not work because only the first prefix is stripped, but since this is garbage, it seems appropriate to return in kind.

has to do with the example quoted.

Ammarpad claimed this task.