The current design keys off autofill after the user enters a value in the name field. A drop down menu is shown allowing the user to select which profile to autofill. If the user does not select a profile, the form will not be autofilled (using AutoFill++). I'll try to clarify this in the doc. Thanks, James
On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher <[email protected]> wrote: > One security concern: > Autofill should not give users information to the page until the user makes > some gesture to accept the autofill choices. > > For the existing autofill, this is done by having the user choose from the > drop down menu. > > The page can read the value of an INPUT field once it is set, so you have > to be careful. I wonder if a solution already exists to support Safari's > autofill. > > -Darin > > > On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins <[email protected]>wrote: > >> 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** <[email protected]> >> 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 <[email protected]> >> - Nick Baum (PM) <[email protected]> >> - Ben Goodger (UI) <[email protected]> >> >> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
