Originally reported at <http://code.google.com/p/chromium/issues/detail?id=45804>. Maciej Stachowiak asked me to report it upstream, since it's reportedly reproducible in Safari as well. I've copied my original report here, adjusted slightly.
What steps will reproduce the problem?
data:text/html,<!doctype html><form><input required><input><button>Submit</button></form>
2. Enter text into second field, leaving first blank
What is the expected result?
Either an error message is presented, or the form submits successfully.
What happens instead?
The form does not submit, but there's no error message. The first input is focused, but that's a very subtle cue, and there's no way for the user to tell if it was focused because it's required, didn't match a pattern, outside allowed min/max/step, . . .
Please provide any additional information below. Attach a screenshot if possible.
Step 3 of the "interactively validate the constraints" algorithm in HTML5 is "Report the problems with the constraints of at least one of the elements given in unhandled invalid controls to the user." <http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation> WebKit does not do this yet.
The result is that using any kind of validation constraint will greatly *hurt* usability for WebKit users. Instead of the form submitting and returning a server-side error, it will return no error at all, and the user will probably conclude that the site is broken. This is actively harmful and will hinder adoption of validation constraints among authors.
I suggest that WebKit either add at least a primitive UI here, or that it hide the feature behind a command-line switch or something until it's usable. Since I've been told this made it into a Safari release, I'd like to further suggest that this change be backported in a bug-fix patch or something, so that web page authors don't have to work around it. The current implementation will be very damaging to author adoption of form constraints as long as any significant number of WebKit browsers with the issue remain in the wild.
Probably you are interested in Bug#40218 and Bug#40520.
> I suggest that WebKit either add at least a primitive UI here,
> or that it hide the feature behind a command-line switch or
> something until it's usable.
I agree that it should be disabled, although I don't agree that primitive UI is OK.
As discussed in Bug#40520, we have disabled the interactive validation.
So we can close this bug.
FYI: Chromium Milestone 6 was branched before the patch of Bug#40520 was landed. So Google Chrome 6 will have the interactive validation only for <!DOCTYPE html>.