Last modified: 2014-06-18 22:42:20 UTC
Afterwards it trys to autologin using the username with hash then fails.
Change 129618 had a related patch set uploaded by Yuvipanda: Use username returned from create account API call https://gerrit.wikimedia.org/r/129618
Change 129618 merged by Dbrant: Use username returned from create account API call https://gerrit.wikimedia.org/r/129618
I'm not sure whether it's good to truncate their user name silently, but it's the behavior on desktop too...
We've got three totally different behaviours on four platforms here: 1) Desktop: Refuses to create username because it has a hash in it. 2) iOS: Lets you create the username, but silently truncates everything including and after the hash, then fails to log you in saying that you provided an illegal username. 3) Android and Mobile Web: Lets your create the username, but silently truncates everything including and after the hash, then logs you in successfully to the truncated username. If desktop doesn't let you create these usernames then neither should any of our mobile platforms. I'm unclear what the correct engineering solution is though. Do we change the API used to create accounts to error if you try to include hashes (instead of silently truncating and creating), or do we just include client-side validation?
(In reply to Dan Garry from comment #4) > 1) Desktop: Refuses to create username because it has a hash in it. On desktop an error (or better to say, warning :p as it's ignorable) is shown, but you can ignore the error and go on to create the account, and the rest is the same as Android.
and the error / warning is only applicable to users with JavaScript enabled.
Bug filed in Core for this: bug 64960.
The Upstream bug has been fixed, let me test locally and see if it is ok on the app.
This bug is fixed now.
