possibly tied to ULS and/or ACUX

Seems to be introduced in I957d9f409b0c29f956bcf8a49187cdf27c4f42f8 according to git bisect.

swalling wrote:

I tested this on enwiki prod (which is on 1.22wmf4) and it's working fine.

To note the expected behavior: when I create a username with an underscore, MediaWiki converts it to a space, so effectively usernames with underscores are not allowed. After that, I am able log in with either a space or an underscore.

Beta is apparently down so I can't test, but if I understand correctly logging in as "Selenium user" works and registering as "Selenium_user" still allows to login as "Selenium user"? If yes there's a workaround and no invalid (non-normalised) usernames are created; if not, this would be a critical bug and a blocker of bug 323.

(In reply to comment #4)

login as "Selenium user"? If yes there's a workaround and no invalid
(non-normalised) usernames are created; if not, this would be a critical bug
and a blocker of bug 323.

I think the issue is that a user who types "m_" should reasonably expect to see the two characters that they typed, and not automatically have those characters become something different e.g. "m̠", since "m̠" is an entirely different character than the user typed, and in this case prevents logging in.

swalling wrote:

(In reply to comment #5)

(In reply to comment #4)

login as "Selenium user"? If yes there's a workaround and no invalid
(non-normalised) usernames are created; if not, this would be a critical bug
and a blocker of bug 323.

I think the issue is that a user who types "m_" should reasonably expect to
see
the two characters that they typed, and not automatically have those
characters
become something different e.g. "m̠", since "m̠" is an entirely different
character than the user typed, and in this case prevents logging in.

Okay well that's an enhancement request, not a bug. Your bug report made it sound like users with an underscore were actually prevented from logging in. These users can log in, they just unexpectedly have the underscores turned in to blank spaces.

Sorry, I didn't pay attention to the diacritics... Yes, input method choice should be smarter than that.

I don't think this has anything to do with ACUX. Niklas indicated it's due to a ULS change. It also doesn't have anything to do with space vs. underscore canonicalization, if I understand right. Rather, m_ becomes "m̠", a Unicode combined character of an underlined m.

This seems like a bug to me, unless it's made crystal clear that the user is using a special input method.

(In reply to comment #8)

This seems like a bug to me, unless it's made crystal clear that the user is
using a special input method.

Yes, I'd like to make the case for having the application honor what the user types unless specifically instructed not to do so by that user.

Especially since a user who created a username "zoom_user" would expect to then type "zoom_user" in order to login, would not be aware that "zoom user" would also work instead of the username they created, and who suddenly has that entry unexpectedly changed from "zoom_user" that they typed explicitly to "zoom̠user" that they did not type and is prevented from logging in will be unhappy.

As seen in the screenshot of the bug, IPA input method is activated. When it is activated, you are effectively typing in IPA and hence m_ becomes m̠.

Change the input method to system input method or disable it.

Santosh, I tested with clean cookies (no cookies for the entire beta cluster), went to http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup (signup link from the main page) and confirmed it. I waited for it to load; it pre-focuses the username field (itself a separate bug since the CAPTCHA is earlier). I then immediately started typing Selenium_user, and got Selenium̠user.

It *defaults* to IPA. I'm unclear why this is even an option on English Wikipedia. It shouldn't be commonly needed.

Ok, so this is a regression - ULS enabled IPA by default. changing the title of the bug.

I957d9f409b0c29f956bcf8a49187cdf27c4f42f8 which caused the issue was reverted in
I5c97838ed875364dc35b66a3d6c33d9975b5107e

This is present on Beta, so I'm reopening. You can test the old form with http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin/signup?useNew=0 , but it's the same with the new ( http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin/signup ).

I could not reproduce this on a fresh browser and neither after clearing the cache on the regular browser [new and old signup forms on beta). In both cases IPA was disabled. Preferences from anonymous user visits are stored locally and could interfere if IPA was 'selected by default' earlier due to the regression . Can you please re-try after clearing the cache again? Thanks.

Matthew: Was it intentional that you re-added "Blocks: 38865" and put severity back from "enhancement" to "major" in your edit on May 21st, or was that an interference / browser cache hiccup?

I don't recall making that change, so it may have been unintentional. It was certainly a bug, though, so I'll just set it to High/Normal.

Looks like it was a cache issue, and it is fixed.