We need to come up with a way, if we also want to implement omnibox-style inline autocomplete for web page autofill. (a separate bug). -Ben
On Wed, Oct 21, 2009 at 11:52 PM, Darin Fisher <[email protected]> wrote: > Ah, OK. That sounds like a good solution. I don't know how to implement > that, but maybe there is already a way. > -Darin > > > On Tue, Oct 20, 2009 at 1:54 PM, Nick Baum <[email protected]> wrote: > >> The mocks also show a preview of all the fields when hovering over or >> arrowing to one of the drop-down options. >> Is there a way to do that without showing the values to the page? >> >> -Nick >> >> >> On Tue, Oct 20, 2009 at 12:46 PM, James Hawkins <[email protected]>wrote: >> >>> 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.comwill >>>>> 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 -~----------~----~----~----~------~----~------~--~---
