Note that in Chrome, the feature is totally broken. Clicking the submit button just doesn't do anything, it provides no feedback for the user indicating why it's not working.

In Opera the UI is awkward, an ugly fake tooltip pops up informing the user of the problem, obscuring the content underneath. Clicking the fake tooltip doesn't make it go away.

Suggest revert of r55517.

Aye, I've been having the same issue for a couple weeks now actually (with
chrome) I didn't realize it was the password thing until we were testing it
today just appeared that the buttons weren't working (not only do they not do anything when you try to press them without a password they don't even press down so it appears like they are just deactivated.

ayg wrote:

Reverting r55517 won't fix the problem, I added lots of uses of HTML5 form constraint validation. It looks like WebKit implemented the constraint validation but with no actual UI -- the offending field is focused but with no explanation. This was a really bad decision by them IMO, and we'll have to disable this as long as we have a significant number of affected browsers in circulation. I've poked them on IRC and will file a bug if I don't get a response.

Opera's UI is ugly too, but at least it's mostly functional. Plus it's a minor browser. WebKit is much bigger and its UI here is nonexistent, so we simply can't leave this in. I'll patch Html.php to strip the attributes for now, so that they can be re-enabled everywhere when support is actually useful.

Possibly relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=34945

ayg wrote:

. . . separately, r55517 is a problem because mCreateaccountMail might be set. And hooks might interfere. I'll try to address that too, although it will be moot until the feature is turned back on.

ayg wrote:

Disabled all HTML5 input validation in r67283, backported in r67284. Additionally disabled this specific incorrect code in r67285, so the bug won't come back when r67283 is eventually (I hope) reverted.

ayg wrote:

Filed a bug against Chromium:

http://code.google.com/p/chromium/issues/detail?id=45804

• Bug 23909 has been marked as a duplicate of this bug. ***

jessica wrote:

bug 23909 was filed on my behalf. I'm not too much a regular here. I was the first one to complain in the IRC channel about not being able to create an account using Chrome. That was roughly 2 months ago (maybe more). About 12 hours ago i found myself unable to create an account using the latest Chrome beta (as has become the norm), the brand new Safari from a couple of days ago (it had been my go-to browser prior to updating yesterday), and an older version along with the latest version of Opera. That would be my three browsers i will use. Under duress i had to resort to a version of IE that in most other ways is useless in order to create an account. Point being, it is not just Chrome or/and Opera.

In Chrome clicking "by e-mail" moves the cursor to "Retype password". In Safari it highlights the "Password" field and moves the cursor there. In Opera you get that nice popup telling you the fields are mandatory.

So yeah forgive me for being blunt but this is not resolved or fixed from my end as a user.

has this been reverted? I believe it was fixed for a while when Tim reverted the problem code was it put back in (either by accident or because someone thought it was fixed?)

yea reopening, reconfirmed this is back in and is a very bad bug

It was reverted in trunk and REL1_16, but it wasn't merged into the deployment
version, which currently has required="required" inputs.

ayg wrote:

This is fixed in trunk, so marking FIXED. If you want deployment, you'll have to ask someone with shell access. Try pestering people in irc://irc.freenode.net/wikimedia-tech.

But I thought it wouldn't affect Wikimedia sites, since those have $wgHtml5 = false. There's a separate bug here. Looks like it's related to allowing attributes to be values and not just keys . . . I should just get rid of that.

ayg wrote:

(In reply to comment #12)

But I thought it wouldn't affect Wikimedia sites, since those have $wgHtml5 =
false. There's a separate bug here. Looks like it's related to allowing
attributes to be values and not just keys . . .

Fixed this bug in r67869. Still not deployed, of course.

Please mark all revisions you want deployed with the 1.16wmf4 tag on CR.

ayg wrote:

Okay, marked r67283.

richardg_uk wrote:

This fix in Html::expandAttributes() causes the step attribute to be silently dropped. But the current W3C standard states that a missing step implies step="1", which is more restrictive than the step="any" correctly supplied by HTMLForm::getInputHTML() when the internal type == 'float'.

So an input element with type="number" causes validation error in Chrome when non-integer values specified, even though the input type is internally specified as a float.

Raised as bug 40585.

From comment in includes/Html.php:

// Bug 23769: Blacklist all form validation attributes for now.  Current
// (June 2010) WebKit has no UI, so the form just refuses to submit
// without telling the user why, which is much worse than failing
// server-side validation.  Opera is the only other implementation at
// this time, and has ugly UI, so just kill the feature entirely until
// we have at least one good implementation.

Surely it's time to revisit this decision 4 years later. I was quite surprised when creating a new FormSpecialPage to find that required fields weren't marked as required in the generated html.