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 -~----------~----~----~----~------~----~------~--~---
