Add new function to ChromeClient to manage form validation messages, and use it. The function will be wrapped with a compile-time flag.
Created attachment 163062 [details] Patch 1
Comment on attachment 163062 [details] Patch 1 Can we make ValidationMessage class an abstract class or an interface and add this new mechanism as a subclass of it? Also, could it be this new ChromeClient API a supplement? Introducing new ifdefs are sad. It would be great if we can minimize its impact.
(In reply to comment #2) > (From update of attachment 163062 [details]) > Can we make ValidationMessage class an abstract class or an interface and add this new mechanism as a subclass of it? > Also, could it be this new ChromeClient API a supplement? > Introducing new ifdefs are sad. It would be great if we can minimize its impact. I can move the changes into ValidationMessage class. However I object making a subclass and making the ChromeClient API a supplement. I'm going to remove the current implementation with Shadow DOM when we complete the ChromeClient API implementation for all platforms.
Comment on attachment 163062 [details] Patch 1 (In reply to comment #3) > (In reply to comment #2) > > (From update of attachment 163062 [details] [details]) > > Can we make ValidationMessage class an abstract class or an interface and add this new mechanism as a subclass of it? > > Also, could it be this new ChromeClient API a supplement? > > Introducing new ifdefs are sad. It would be great if we can minimize its impact. > > I can move the changes into ValidationMessage class. However I object making a subclass and making the ChromeClient API a supplement. I'm going to remove the current implementation with Shadow DOM when we complete the ChromeClient API implementation for all platforms. That makes sense. What do you think about per-validation-message state tracking? If WebKit layer needs to maintain element-to-state map, probably we could morph ValidationMessage to ValidationMessageClient (or something) which is implemented by WebKit layer. Such object could also be used to notify relayout change, etc.
(In reply to comment #4) > What do you think about per-validation-message state tracking? > If WebKit layer needs to maintain element-to-state map, probably we could morph > ValidationMessage to ValidationMessageClient (or something) which is implemented by > WebKit layer. Such object could also be used to notify relayout change, etc. The client approach sounds good. It makes the patch cleaner. I have posted a patch to prepare the client approach to Bug 96365.
Created attachment 163496 [details] Patch 2
Comment on attachment 163496 [details] Patch 2 Looks good. ValidationMessageClient could be per-Element basis. But it might be overdone.
Comment on attachment 163496 [details] Patch 2 Clearing flags on attachment: 163496 Committed r128394: <http://trac.webkit.org/changeset/128394>
All reviewed patches have been landed. Closing bug.