[Webkit-unassigned] [Bug 110375] Hook FormAssociatedElement, HTMLFormElement to notify EditorClient of form changes after a page has loaded

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110375





--- Comment #22 from Elliott Sprehn <esprehn at chromium.org>  2013-02-21 14:09:27 PST ---
(In reply to comment #18)
> (From update of attachment 189594 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=189594&action=review
> 
> > Source/WebCore/page/EditorClient.h:121
> > +    virtual void didAssociateInput(Element*) = 0;
> > +    virtual void didAddForm(Element*) = 0;
> > +
> 
> I don't think these callbacks belong in EditorClient. EditorClient is for editing operations.
> Detecting a change in associated form control is nothing to do with editing operations.

I suggested we put them there because they're the concern of any editor that's implementing autocomplete or autofill. Right now the autocomplete implementation in Chromium needs to crawl the entire document on page load to find form inputs, and then we can't figure out if the page changes or there's dynamic forms. Dane had originally wanted to use MutationObserver, but that makes many DOM operations much slower since we start adding mutation records everywhere.  I suggested this approach instead.

Do you have a suggestion for where you'd want these instead, could we the callbacks differently? EditorClient seems natural, that's also where spell checking and other things are which tie in with autocomplete. ex. Spellcheck should know all your autocomplete terms are not typos, and the spell check suggestion bubbles (the iOS thingers) should suggest text that's anywhere in the current form.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.