Hi, please read the inlined proposed design for AutoFill++. Any feedback
and comments are appreciated.
Thanks,
James Hawkins
*AutoFill++*
*Status:* *Draft* (as of 2009-10-16)
*James Hawkins** <jhawk...@chromium.org>
Modified: Fri Oct 16 2009
*
Objective The purpose of this document is to describe a significant
improvement in the current form autofill feature of Google Chrome. The
current implementation is less of a form autofill and more of a form
history. This approach has some limitations:
- Values are saved per-site, so a Name value saved on penguin.com will
not be suggested for the Name field on turtle.com.
- The form must be filled out field-by-field.
I am proposing a new approach to form filling based on the client/server
statistic-based model implemented by Google Toolbar. This feature provides
the following benefits:
- Forms are completely auto-filled.
- Values are saved in user profiles, so the Name field can be auto-filled
for a form on a site one has never visited.
Background The main problem with the current autofill feature is that
the user must move from field to field to fill out a form, even when each
field can be auto-filled. The history is site-specific, so the user must
enter form data for each site before autofill can be useful.
Overview
To use the AutoFill++ feature in Google Chrome, the user must enter personal
information (name, address, email, etc.) into a form on any site and submit
this form. An infobar will ask the user if he wants to enable autofill, and
if so, AutoFill++ will parse the form data and query the autofill server for
the field types. If the server knows the field types for the form on this
particular site, AutoFill++ will match the data with the fields; otherwise,
a heuristic based on the names of the fields and how they are layed out on
the form is used to make this match. The map of (field, data) will then be
saved in the user form data database. When the user starts entering
information into any other form, a list of saved profiles will be presented
to the user in a selection drop-down. After picking a profile, AutoFill++
will autofill all fields that it knows about and has information in the
database for.
The user will be able to enter additional profile information at any time
through the AutoFill++ dialog. This dialog will be shown after the user
first enters form information, and will also be available through the
options dialog.
Note that no personal information will be sent to the autofill server, just
the field types determined by the heuristics.
Detailed Design The first step in implementing AutoFill++ is to rename the
current AutofillForm data structures to better match their behavior:
FormFieldHistory.
Just like Toolbar AutoFill++, the client will implement some strategies to
reduce the bandwitdth on the autofill server. These include:
- Ignore common search forms by ignoring forms that contain only one
textfield with an id of "q".
- Ignore forms using the GET method to submit for data.
- Ignore forms that have the word "search" in the target url for that
form.
- Using a flag in the query response from the server to tell the client
whether or not it should upload the data if a user submits this form.
*Data Structure*
*Description*
*AutoFillForm*
The container that holds the (field, value) pairs, parsed from HTML.
*RenderViewHostDelegate::AutoFill*
An interface implemented by a class that wants to be notified of AutoFill
events from the RenderView
*AutoFillService*
The main AutoFill++ class. Coordinates between the RenderView, the autofill
server, and the PersonalDatabaseManager Each TabContents has one, and each
instance is lazily created.
*AutoFillQueryXMLParser
*Builds and parses XML queries that are sent to and received from the
autofill server.
*AutoFillDownloadThread*
Spins off a new thread to download/upload data to the autofill server.
*AutoFillProfileDialog*
The UI for displaying the AutoFill++ profile dialog.
*PersonalDatabaseManager*
The gateway between the AutoFillService and the profile database.
*AutoFillProfile*
Contains all available personal information provided by the user. This is
written to and read from the database.
The following is a description of the program flow for a typical autofill
session.
1. User fills out and submits form.
- RenderView::willSubmitForm - An *AutoFillForm* is created using *
AutoFillForm::**Create*, which parses the form fields and values from
a given WebForm.
- ViewHostMsg_AutoFillFormSubmitted - Sends an IPC to the browser's
render view host containing a map of the fields and values.
- *RenderViewHostDelegate::AutoFill->AutoFillFormSubmitted*
- *AutoFillService::HandleSubmit*
- *AutoFillQueryXMLParser* - Creates the XML
representation of the form data, in the format
specified by the autofill
communication protocol.
- *AutoFillDownloadThread* - Uploads the XML to the
autofill server.
- Response from the server is handled by the *
AutoFillDownloadThread*.
2. Infobar - "Do you want Chrome to save this info?"
- No - Terminate the AutoFillService instance.
- Yes
- *AutoFillProfileDialog* - Allows the user to add/edit personal
information for this profile.
- *PersonalDatabaseManager* - Saves the personal information to the
database.
3. User begins entering the Name field on a form.
- EditorClientImpl::handleKeyboardEvent - signaled when the user types
in an edit field.
- *AutoFillDownloadThread* - Sends the site properties to the
autofill server and downloads the known form field types.
- *EditorClientImpl::ShowFormAutoFillForNode* - Shows the list of
autofill profiles that match the entered text.
- *EditorClientImpl::AutoFillForm* - Fills out all fields in the
form where we know the type of the field and have data
avaiable for that
type.
Communication Protocol (and fix this color)TODO
Mocks*Insert link to mocks once they are published.*
Project
Google Chrome
Code LocationThe AutoFill++ service code will reside in:
*chrome/browser/autofill*
Group Members
- James Hawkins <jhawk...@chromium.org>
- Nick Baum (PM) <nickb...@chromium.org>
- Ben Goodger (UI) <b...@chromium.org>
Internationalization and Localization Handling for internationalization and
localization for AutoFill++ is primarily handled by the autofill server. If
the server fails to return field types for a form, the heuristics will not
match non-english field names.
Security ConsiderationsHow will the user's personal information be secured?
How do we currently store saved passwords?
Privacy Considerations AutoFill++ will store personal information in the
profile database, but none of that information will be uploaded to the
autofill server. All URLs sent to the server will be hashed.
Testing Plan Browser and unit tests will be added to verify functionality of
AutoFill++. A mock server will be implemented to simulate communication
with the autofill server. The following sub-units will be tested:
- Infobar
- Form upload/download
- Database
- Form autofilling (webkit/glue)
Work Estimates
*TBD*
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
