Habitica: No indication of why sign up button is disabled

[sersorrel]

When signing up to Habitica, the "Get Started Now!" button isn't clickable unless all fields are filled in and the email address provided is valid. However, there's no indication of what is wrong if the button is clicked when these conditions are not met. Leaving aside the issue of email validation (I'm pretty sure a@a shouldn't be accepted...), there should probably be some kind of visual feedback to tell the user what needs fixing.

Judging by what's in common/locales/en/front.json, messages should be appearing (e.g. "notAnEmail": "Invalid email address."), but I'm definitely not seeing any.

Edit: "Invalid email address." pops up in an alert with a@a after pressing the sign up button, but entering just "a" as the email address disables the sign up button and provides no feedback of what's wrong.

[Alys]

When I fill in all the fields but use an invalid email address (ss@ss), I
can click the button but then see a popup saying "Invalid email address".
If you're not seeing that, close and reopen your browser (that will reset
the browser's setting to disable popups, in case you've selected that at
some time in the past). If you still don't see it, tell us which browser
and OS you're using.

You're correct that it doesn't tell the user which fields they haven't
filled in, but I think it should be fairly clear. We're redesigning the
website in the not too distant future, so this is probably something we
could work on then (e.g., move the field names out of the fields themselves

• placeholder field names are not good for usability in most cases, and add
  some extra JavaScript hints). I think it's clear enough now that it doesn't
  need fixing before then.

[crookedneighbor]

Fun fact: technically a@a _is_ a valid email address because the earliest email happened over p2p networks, so it didn't require a website domain, just an identifier of the computer you were on.

But yes, in the redesign, that should all be considered.

[sersorrel]

Please can you consider using the same validation rules on the server and client in the redesign? It seems odd to allow something to be submitted, but then reject it with an error message when there's clearly _some_ checking being done client-side.

[audiolion]

Yeah id agree normal client side validation would help show hey this is a required field and reduce load on server. Might be obviously worked in during the new frontend but a good point nonetheless

[paglias]

What we're using on the client side are native HTML5 validations and their interface is implemented directly by browsers so that could be a reason why someone is seeing messages and someone not.

[sersorrel]

Ah, that might explain it. I thought Chrome had a popup for when HTML5 validation failed, but I guess something somewhere (whether in Habit, Chrome, Ubuntu or something else) broke it for me.

[lemoness]

This has been changed, so I am closing this ticket.