RESOLVED FIXED Bug 40747
HTML form validation constraints should not be honored until UI is provided 
https://bugs.webkit.org/show_bug.cgi?id=40747
Summary HTML form validation constraints should not be honored until UI is provided
Aryeh Gregor
Reported 2010-06-16 16:59:58 PDT
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? 1. Visit: data:text/html,<!doctype html><form><input required><input><button>Submit</button></form> 2. Enter text into second field, leaving first blank 3. Submit 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. Because of this WebKit behavior, MediaWiki has dropped form validation constraints from version 1.16: <https://bugzilla.wikimedia.org/show_bug.cgi?id=23769>. They create negative value for our users. When we have good enough implementations in some browser to turn them back on, we'll be forced to use JavaScript hacks to do UA detection until the affected WebKit versions are no longer relevant, rather than being able to serve simple declarative markup. 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.
Attachments
Add attachment proposed patch, testcase, etc.
Kent Tamura
Comment 1 2010-06-16 18:52:11 PDT
Probably you are interested in Bug#40218 and Bug#40520.
Alexey Proskuryakov
Comment 2 2010-06-25 13:53:53 PDT
> 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.
Kent Tamura
Comment 3 2010-07-27 00:36:00 PDT
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>.
Note You need to log in before you can comment on or make changes to this bug.