Some tip from other bugs this depends on: 1. Form control elements can be in a "no-validate state" that is controlled by "novalidate" and "formNoValidate" attributes, plus some more condition. This snippet could be of help: bool HTMLFormControlElement::isInNoValidateState() const { return (isSuccessfulSubmitButton() && formNoValidate()) || m_form->novalidate(); } 2. HTMLFormElement::checkValidity() needs to be adapted to deal with "unhandled invalid controls" (as per TODO comment). Actually it just iterates over form elements calling checkValidity() (that fires the invalid event, as per specs), but it must also return a list of invalid form controls that haven't been handled through the invalid event. The following snippet might be of some help (was part of the proposed patch for bug 27452): bool checkValidity(Vector<HTMLFormControlElement*>* unhandledInvalidControls = 0); bool HTMLFormElement::checkValidity(Vector<HTMLFormControlElement*>* unhandledInvalidControls) { Vector<HTMLFormControlElement*> invalidControls; for (unsigned i = 0; i < formElements.size(); ++i) { HTMLFormControlElement* control = formElements[i]; if (control->willValidate() && !control->validity()->valid()) invalidControls.append(control); } if (invalidControls.isEmpty()) return true; for (unsigned n = 0; n < invalidControls.size(); ++n) { HTMLFormControlElement* invalidControl = invalidControls[n]; bool eventCanceled = invalidControl->dispatchEvent(eventNames().invalidEvent, false, true); if (eventCanceled && unhandledInvalidControls) unhandledInvalidControls->append(invalidControl); } return false; }

I have started implementation.

(In reply to comment #2) > I have started implementation. Good! I think you'll be needing support for the validationMessage for interactive validation step 3 (4.10.15.2) [bug 27959], I'm gonna speed it up.

> Good! I think you'll be needing support for the validationMessage for > interactive validation step 3 (4.10.15.2) [bug 27959], I'm gonna speed it up. That's right! The implementation requires validationMessage().

Created attachment 38918 [details] Demo patch A workable demo patch. This is not ready to be reviewed. It has no tests and it depends on bug#27959 and bug#28868.

I'll use Balloon Tooltip for Windows to show validation messages. http://msdn.microsoft.com/en-us/library/bb760250(VS.85).aspx I don't know if Mac OS has a corresponding control.

Created attachment 40698 [details] Incomplete patch (rev.0) I'd like to ask comments on the patch though it is incomplete. The patch will add the following behavior: - Show/hide a validation message when an invalid form control gets/losts the focus The way to show messages depends on each of platforms. - Prevent a form submission if the form has invalid controls TODO: - Add tests - Build file changes for other platforms - Provide ChangeLog.

Comment on attachment 40698 [details] Incomplete patch (rev.0) As you say, the patch is incomplete. No ChangeLog. No tests. If you'd like feedback on this patch, I recommend asking the relevant people on IRC or email. Having this patch in the review queue just makes it harder to review complete patches.

I split this to 3 patches. Bug#31716, Bug#31718 and this will have patches.

I think that form validation should be disabled until: - a solution is found for the compatibility problem with "required" attribute name; - UI for correcting problems is implemented (as tracked by bug 31718/bug 40747). Currently the user experience is just horrible.

I agree with Alexey. In 2008, I wrote an app to the HTML5 spec, then backported the validation API to JavaScript to support then-existing browsers. I've seen the app break a couple of times due to changes in WebKit (which Tamura is always eager to fix). If you go to http://beta.insightdining.com/surveys/limon/ without the WebKit validator, the page scrolls smoothly to take you to an invalid element on form submission. Since the validation constraints have been added, the page abruptly jumps to the first invalid <input/>. I'm sure there are users who don't understand what's going on when this happens. For that matter, I wasn't even sure what was going on when I was debugging #40591.

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

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

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

This ticket was created as an enhancement, but the last few tickets which were marked as duplicate to this are more critical. It seems this problem now affects normal validation and not only the JavaScript API. IMHO the priority/importance of this ticket should be increased.

This always affected “normal validation”, not just JavaScript API, and that validation is a new feature, and one that is not implemented yet in WebKit. I understand that you would like to see the feature!

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

Is anyone currently working on this? It was submitted 7 years ago, and Safari is now the only browser whose current version will submit a form with invalid constraints.

<rdar://problem/28636170>

*** This bug has been marked as a duplicate of bug 164382 ***

(In reply to comment #18) > Is anyone currently working on this? It was submitted 7 years ago, and > Safari is now the only browser whose current version will submit a form with > invalid constraints. Safari Technology Preview 19 has this enabled: https://webkit.org/blog/7093/release-notes-for-safari-technology-preview-19/