demo: https://googlechrome.github.io/samples/report-validity/

Created attachment 291704 [details] Patch

Comment on attachment 291704 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=291704&action=review > Source/WebCore/html/HTMLFormControlElement.cpp:512 > + String message("An invalid form control with name='%name' is not focusable."); > + message.replace("%name", name()); This could be more efficient if you used makeString("An invalid form control with name=', name(), "' is not focusable.")

Comment on attachment 291704 [details] Patch Attachment 291704 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/2288377 New failing tests: imported/w3c/web-platform-tests/html/semantics/forms/constraints/form-validation-reportValidity.html

Created attachment 291706 [details] Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6

Created attachment 291708 [details] Patch

Comment on attachment 291708 [details] Patch Attachment 291708 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/2288770 New failing tests: imported/w3c/web-platform-tests/html/semantics/forms/constraints/form-validation-reportValidity.html

Created attachment 291710 [details] Archive of layout-test-results from ews126 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews126 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6

Created attachment 291718 [details] Patch

Comment on attachment 291718 [details] Patch Clearing flags on attachment: 291718 Committed r207380: <http://trac.webkit.org/changeset/207380>

All reviewed patches have been landed. Closing bug.

Implementing reportValidity() without enabling interactive validation is very inconsistent. Does this reportValidity() implementation use the old ShadowDOM-based bubble?

(In reply to comment #12) > Implementing reportValidity() without enabling interactive validation is > very inconsistent. Oh, I did not realize that interactive validation was disabled. Let me look into it. I agree that both should be enabled for consistency. > > Does this reportValidity() implementation use the old ShadowDOM-based bubble? I have not worked on this part, I basically reused code from interactive form validation to make reportValidity() work. I tested that bubbles showed as expected. I have just looked into it and it does appear it currently uses an old ShadowDOM based implementation (that you wrote a long time ago). I need to talk to people about this as I assume this may need improvements.

<rdar://problem/28803331>

(In reply to comment #13) > I have just looked into it and it does appear it currently uses an old > ShadowDOM based implementation (that you wrote a long time ago). I need to > talk to people about this as I assume this may need improvements. As I wrote in https://bugs.webkit.org/show_bug.cgi?id=95527#c0, The ShadowDOM implementation had multiple problems. I strongly recommend to implement ValidationMessageClient with native widgets.

(In reply to comment #15) > (In reply to comment #13) > > I have just looked into it and it does appear it currently uses an old > > ShadowDOM based implementation (that you wrote a long time ago). I need to > > talk to people about this as I assume this may need improvements. > > As I wrote in https://bugs.webkit.org/show_bug.cgi?id=95527#c0, The > ShadowDOM implementation had multiple problems. I strongly recommend to > implement ValidationMessageClient with native widgets. Yes, I understand, thanks. I'm currently discussing this with others.