After reading http://avatraxiom.livejournal.com/97999.html it seemed like a good idea to handle form autocomplete inside WebKit to void every port having their own incompatible version of it.
Do you mean autocomplete or autofill? The article that you link to appears to conflate the two. Autofill is when the browser attempts to recognize a form and auto-populate it, either automatically when the page loads or when the user triggers it. This may use data from the user's address book, saved usernames / passwords, or previous forms. Autocomplete is typically triggered when typing into a form field. The browser searches the partial input and offers to expand it to a previously entered form field value or other saved data. What do you mean by "handle [it] inside WebKit"? Many WebKit-using applications have no desire for autocomplete or autofill. Those applications that do want it may want quite different behavior.
I'm pretty sure both the article and I are talking about what you call autofill, since this is the only one of those two features happening on page load. And with "handle inside Webkit", I mean a common API inside the Webkit core that manages when to autofill form fields and reduces the amount of work required by the different ports to get it working. The default implementation of course would just not autofill anything. Do you think applications would have different needs for autofill? In particular, I can't come up with any different needs that are worth annoying web developers with with incompatibilities between browsers?
(In reply to comment #2) > And with "handle inside Webkit", I mean a common API inside the Webkit core > that manages when to autofill form fields and reduces the amount of work > required by the different ports to get it working. The default implementation > of course would just not autofill anything. Autofill is conceptually quite simple. At the appropriate time you find forms on the page, attempt to match them against stored data in some fashion, and fill in any data that matches the form. Finding forms is relatively simple given a functioning DOM API. Matching form fields against stored data is an area that seems application-specific and hard to generalize. Filling in data is again a matter of using the DOM APIs. The timing aspect is interesting, but I'm not sure how that could be addressed within WebKit. This may be a matter of communication between browser developers to ensure consistency. It may be a matter of firing a delegate method at an appropriate time. It's hard to say. Did you have any specific suggestions for the sort of functionality that WebKit could provide in this area? > Do you think applications would have different needs for autofill? In > particular, I can't come up with any different needs that are worth annoying > web developers with with incompatibilities between browsers? It's not clear to me how autofill has any impact on developers beyond the timing aspect of it. And yes, I think applications have different needs for autofill. The biggest difference is in terms of data sources for the autofill.
Autofill is currently handled by Safari (not WebKit). https://support.apple.com/guide/safari/autofill-ibrwa005/mac I'm closing it. If there's a specific use case not addressed by the current autofill features of Safari, please open a bug on https://www.apple.com/feedback/safari.html