Closed Bug 160735 Opened 23 years ago Closed 20 years ago

Form Manager (Auto-fill, Wallet)

Categories

(Camino Graveyard :: General, enhancement)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tfo, Assigned: mikepinkerton)

References

Details

(Whiteboard: Through Address Book APIs?)

i'd love to see Chimera support this standard Mozilla tool.
This is unlikely to happen. It's a huge thing in Mozilla, and Chimera's supposed to be simple. Chimera will get basic username and password storage by implementing support for the Keychain Manager (bug 152485). Suggest WONTFIX.
i thought Chimera was just supposed to be a browser, which, by definition, is much simpler than the Mozilla project as a whole. still, this feature, i think, is an almost requisite part of contemporary browsers, no matter how simple, considering that more and more websites are using forms as a standard matter of course. i think Chimera will fail to be as great a success as it could otherwise be if it lacks this feature by 1.0... i know that i, for one, will return to Mozilla if this get's flagged WONTFIX. that's not a threat so much as an indicator of user preference. and i guess that's what the democratic process of open source software development is all about, but i'm so impressed with Chimera, to date, that i _do_ use it as my default browser. i _don't_ have time to implement form manager, but Mozilla's heading, i think, to a Mach-o build, eventually, as the OS X default. if Chimera's not going to go the whole mile as a browser, then Mozilla will (and already has, just not (easily) natively).
Thomas, I think you hit on a very important point. Mozilla will always be there for advanced users who want lots of functionality, and it gets to be a better Mac app all the time. Chimera will, at least for the forseeable future, be a lightweight, fast browser without a lot of bells and whistles. Really, Chimera at this point is and should be the technology demonstration of Gecko embedding on the Mac that Mozilla always aspired to be but fell short. I hope to see other developers start projects to create more complex versions of Chimera, but this one should remain simple.
yeah, i guess i'm just surprised. i wouldn't have guessed that Form Manager would've been such a huge chunk of code compared to Password Manager, which Chimera _will_ have. is Password Manager feasible mainly because of the Keychain system? i guess the main reason i've continued to use Chimera on a daily basis is to help pound out browser bugs and figure out which features i most hope to see. i'd say Password Manager and Form Manager are the two i miss most on a daily basis. i guess, not being a developer (yet), i'll take your word for it that Form Manager would reduce claims of Chimera being "lightweight", but i still think that the developer community of Chimera would do well to do a cost/benefit analysis for their user community [insert appropriate Asa flame about the Mozilla project, here... :)].
We aren't using Password Manager at all either; we're using Mac OS X's built in keychain manager and throwing away the gobs of redundant platform independent code from Moz (if that patch ever get's checked in; it's still targeted 0.4, but I think it's basically on hold as the developers are in bug killing mode). I think we could do a similar thing for the Forms manager, and not have to forsake it completely. Here's my idea: since Jaguar has a systemwide address book, why don't we just make an Edit>Fill in Forms menu item, and an Autofill button that you can add using Customize Toolbar..., and then have these commands simply fill in forms using the information from your address book card. We can easily get this info using the new APIs, without adding any bloat to Chimera. This should be very inobtrusive to new users, and very discoverable and easy to use by them (it will just magically work, without them having to set up any complicated manager, or even fill in a preference pane like they have to in IE, "It Just Works"). Feedback?
well, if it transparently simulates the functionality of Form Manager as it exists in Mozilla (and most other major browsers, these days), i'm all for it. unfortunately, i'm going to be less valuable in terms of considering the technical aspects of tying Address Book into Chimera, although i was going to see if anyone knew of a good way to use some native aspect of OS X to accomplish this. sounds like you've hit on a pretty good one. the only question i have about both of these native interfaces (Keychain for passwords; Address Book for forms) is: will there be a way via Chimera to manipulate the values that doesn't require launching an external app?
*** Bug 168290 has been marked as a duplicate of this bug. ***
Summary: [RFE] Form Manager → Form Manager
Summary: Form Manager → Form Manager (Auto-fill)
I would think that using the AddressBook framework's Me record as the data source for AutoFill would be the best approach. However, the AddressBook framework is not available prior to 10.2. Perhaps a bit of code to check the OS version, if it's there, allow the appropriate button to be added to the toolbar. I would imagine that a good portion of the code being used for the keychain passwording system could be used here. I'm sure that routine must have code to look at the contents of the HTML form, pull the password and username from keychain, and then put the results into the final output for the user. Take that code, add to it the ability to query for fields other than "username" and "password", then query against the AddressBook framework and push to final output. Dammit, I wish I knew how to program Cocoa.
Re: Comment #8 From Jason Deraleau 2002-11-18 11:53 > I would think that using the AddressBook framework's Me record as the data > source for AutoFill would be the best approach. I feel ashamed that I didn't think of that. > However, the AddressBook framework is not available prior to 10.2. Whilst right now, many still use 10.1, this is going to change over the next few months. 10.3 and 10.4 may add yet additional services like this, and we can't keep thinking of backwards compatibility [actually, at this moment, this should in fact be posted to the newsgroups. Whoops.], can we? > Dammit, I wish I knew how to program Cocoa. Well, ditto. I would love to be able to create a Cocoa BugZilla front-end. Sigh.
i guess the only problem i have with this suggestion is that you're then limited to the Address Book API for what gets stored. unless Address Book has the ability to add custom form fields. the nice thing about Mozilla's Form Manager is the ability to pre-fill any form field. Tools->Form Manager->Edit Form Info then look at Other Saved Information->URL-Specific i don't know if Address Book is that flexible.
i don't know if Address Book is that flexible. "The groups and people are stored in an extensible. That means you can add properties to the Address Book records that other applications will ignore." http://developer.apple.com/techpubs/macosx/AdditionalTechnologies/AddressBook/
well, then. by all means!
> well, then. by all means! Like I'd posted to the mailing list the other day, it seems like all of the ingredients are there, just no one is mixing...
Summary: Form Manager (Auto-fill) → Form Manager (Auto-fill, Wallet)
Whiteboard: Through Address Book APIs?
I really feel that this is a feature that a lot of users will appreciate. Especially with the holiday season coming up and online Christmas shopping set to reach an all time high. Think we could bang this out in the next few weeks? Perhaps a change in priority? Seems the votes are collecting as well. To reiterate my thoughts: Have this be a 10.2 only feature for now. A routine detects what version of the OS is running at startup. If it's 10.2 or greater, a button labeled "Form AutoFill" is added to the list of toolbar buttons. It is not shown by default, but is available upon selecting Customize Toolbar. The two parts needed for performing form auto fill are: 1) A method of determining what fields are in the form as well as stuffing the correct values in those fields. (Input/Output) This code is already present in the Keychain passwording feature. It just needs to be modified to handle more form fields. 2) A method of retrieving and storing data to put in the form. For this, I suggest using the Jaguar AddressBook framework. This makes the feature 10.2 only, but it also reduces the overall code required, since a database doesn't need to be developed to store the form information. Instead, just query the Me record of the Address Book and then use that data. I would suggest filling in any available data that is present in the Address Book's Me record. The AddressBook framework is extensible, so if a need for more functionality becomes apparent, code can be created to expand WITHOUT OTHER APPLICATIONS BEING AFFECTED. Anyone up to the challenge? I'm more than happy to write some basic documentation on using it once the feature is implemented.
->simon
Assignee: saari → sfraser
QA Contact: winnie → sairuh
How would this work if the ME card had multiple entries (for e-mail, phone #, etc.)?
> How would this work if the ME card had multiple entries (for e-mail, phone #, etc.)? Good question. Perhaps go with the entries that are for home first?
Here's the answer, from http://developer.apple.com/techpubs/macosx/AdditionalTechnologies/AddressBook/Tasks/AccessingData.html "Many properties can have multiple values. For example, a person can have several addresses, including work, home, summer home, and mailing addresses... Each multi-value list also has a primary value, which is the item the user most strongly associates with that person. For example, friends may have both home and work addresses, but the home address is their primary address. And coworkers may have both home and work phone numbers, but the work number is their primary number. To get the identifier for a multi-value list's primary value, use the method primaryIdentifier or the function ABMultiValueCopyPrimaryIdentifier" As you can see, the Address Book Framework does all the work:
As per Comment 18, I was just wondering what UI element let's you, in Address Book, define this primary. I cannot seem to figure out how that is set.
I'm not sure you can change it; based on Apple's documentation, it seems that Address Book decides, for example work is primary for the coworkers group, and home is primary for the friends group. Of course, all we care about is the Me card, and I don't know about that. Maybe we should have a pop-up menu on the toolbar item and a submenu on the menu item that let you pick what location you want to use, if you have info for more than one location on your Me card.
I don't think that would work very well, given that many pages ask for both a home phone and a work phone, a home address and a work address. I believe with IE, it assumes that if the page just asks for a phone then the home phone is used. What I think would work better is a radio button somewhere (such as preferences) that states whether this computer is used as a home computer or a work computer. Does Apple store that info somewhere? I think they ask it when you first set up your Mac OS X. The other thing about IE, is that if autofill puts in the wrong address (for instance), it can quickly be corrected using AutoComplete, where you can start typing the correct address and the rest will appear to the right of the cursor. AutoComplete is another one of those marvelously useful technologies that I wondered how I ever lived without, and it requires minimal UI. But I suppose that is a different bug.
That's a good point; I think we are better off just going with the primary values. I don't think there is ever much need to fill in your work address anyways, although as you point out it would be good to get the work phone number, if one is entered. The Address Book also tracks mobile, fax, etc., and we could auto-fill these if they are present.
I am quite close to finishing autocomplete for forms. It is very lightweight, and doesn't make text entry any less responsive. The question is - do you want autofill (ie. some sort of button that you press to fill in the values for you, without any typing). It could also be done automatically when pages are loaded - but I don't think this is a good idea (I hate apps that do stuff you didn't ask them to). I have managed to copy & paste some of the Mozilla code that does this into Chimera, but it needs a lot more work before it can be used with the Address Book API. If autocomplete is added, is there any reason to have autofill too?
I think autocomplete alone will be sufficient.
what is the difference between auto-complete and auto-fill?
I think they are both very valuable. Just to clarify the terminology, "Autofill" is what most of this bug addresses, where you push a button or select a menu item and common values such as name and address are pulled from the "me" record and inserted in appropriately named fields. One click and bam -- most of the form is filled. "Autocomplete", where you start to type something and the application finishes it to the right of the cursor is also valuable. "Autocomplete" in IE is very nice, where you can type something and then right click on it to add it to the "autocomplete list". Then next time you start to type it it can guess what you are typing based on that list of values. One of the reasons "Autocomplete" is so handy is that "Autofill" does not always get the right values in the right spot (not all Web designers use field names that the application can use to guess what they are for), so you can type over a home address with a work address for example, and still only have to type a couple of letters. From what you are saying in comment #23, you have almost got "autocomplete" done. That is great news, but autofill is still very valuable too. With one click the form can often be almost completely filled without typing. "autofill" is then good for cleaning up the parts that "autocomplete" missed.
> The question is - do you want autofill Yes. That is the main purpose of this bug. AutoComplete is nice, but AutoFill is much nicer :) Especially when you shop a lot online (too bad we missed my Christmas shopping...)
Out of curiousity... Is the AutoComplete you've implemented based only on values from Address Book? If so, could they instead be anything I've ever entered in any field in any form?
Autocomplete will only complete values from your own details in the address book. It would be easy to add the ability to autocomplete a subset of others details, eg. your friends names and email addresses (but not their addresses and phone numbers etc. for the sake of performance). This may be useful for webmail applications. My patch will not enter data in to the Address book, for that you can just use the Address Book application itself. It will also not store data like credit card numbers - Apple said that the Address Book is not secure enough for this purpose.
It seems to me that the address book me record would be better suited for an autofill button, and that autocomplete should be from a list of user defined values.
But we certainly do want the things in the Address Book to get AutoCompleted, we just also want to be able to do custom values as well. If we can get a patch that takes care of Address Book AutoComplete and AutoFill, that's a start at least. Then, we'll probably need a new tab in one of the preference panes to manage custom autocomplete and autofill values, if we include that. In the interim, if we get the Address Book integration done, you can make a custom field for anything you enter a lot. Also, I think we should _not_ use a system like IE where it autocomletes anything you have previously entered into a form: we have a shared computer in my apartment, and if you go to the university's online access, IE will autofill other people's social security numbers and PIN numbers!
Off-topic comment (shoot me if you can) --------------------------------------- > Also, I think we should _not_ use a system like IE > where it autocomletes anything you have previously entered into a form: we have > a shared computer in my apartment You all share the same user account? That's quite a bad idea.
I think the IE for Mac way is fine. You have to tell IE that you want the value to be part of the autocomplete list, and the list can be edited in prefs. People that mess with prefs or right click on form values aught to know what they are doing. If the autocomplete list is a text file somewhere, then the administrator could just delete it or replace every so often or have an Applescript run on log-in to do so. Prefs for "autofill" can consist of a button that launches Address Book, and perhaps an "on/off" switch. If "autocomplete" is stored as lines in a text file, that file could be edited by hand until a pref pane is designed.
There is no need to have a preference pane for editing the values in the Address Book. This is what the Address Book application is for. There is also no need to store values in a text file - this is what the Address Book API is for. As for a method of adding other autocomplete-able values, what would they be? Could they not be stored in your Address Book card?
Right clicking on a value hand entered on a form and selecting "Add to AutoComplete List" is the most convenient. In IE, the AutoFill tries to identify the fields to fill in by looking at the control name. I believe if it can't ID it that way, it looks at the text preceding it as being some sort of label. AutoComplete, on the other hand, only looks at what you are typing and compares it to the list of AutoComplete values. So AutoComplete doesn't actually need the same sort of matched name-value pairs that are tracked in the Address Book. Address Book seems like overkill for the AutoComplete. AutoComplete is more versatile without being tied to a named field.
Autocomplete isn't overkill - it is a fairly small amount of code that takes advantage of an existing feature (the Address Book). Comparing the text being entered with the start of the strings stored in the Address Book is trivial. However, autofill is a _lot_ more difficult to do right. You have already stated that it is necessary to look for text preceeding the text field. Then, this text (which isn't always in English) must be analysed to get the proper value to look up in the Address Book (think of all the different ways to ask for your name/first name/christian name etc.). This is more code than autocomplete, and as such _is_ overkill for a lightweight browser like Chimera.
Well, it sounds like a good start, anyway. I thought the value of using the Adress Book is that all the values are named, which is handy for AutoFill, but not for AutoComplete. I imagine that you would then have to ask for a name for every value the user wanted to add, or else have some sort of alert telling the user that the Adress Book is being launched so they can do it themselves. Just dumping the unnamed values into a text file seems a lot simpler to me. Since this bug is about AutoFill, I still think that is an incredibly useful feature that many people would expect from a modern browser, especially if they have used it in I.E. Doesn't Mozilla have the code you need to identify the fields?
Sorry, I should have clarified that I was talking about IE on Windows ME, which simply remembers all the things you have typed into a field in the past and shows you a little pop-up list of them, like autocomplete in the URL bar: I think _that_ is a bad idea, but having a CM command to allow you to have something remembered is good. As for AutoFill, Chimera already has the code needed to identify form names: that's how we autofill user names and passwords using the Keychain. This bug simply proposes that we extend that functionality to also autofill other elements using the Address Book. Perhaps this bug should be split into parts: an autofill command using the address book, autcomplete using the address book, and autocomplete using custom data.
i agree with comment 38: perhaps it's most sensible for Form Manager to be a meta-bug for precisely those components.
> Perhaps this bug should be split into parts: an autofill command using the > address book, autcomplete using the address book, and > autocomplete using custom data. Heh... it's pretty much only been for AutoFill from the beginning. I think there might have been some confusion along the way, but the intent of the bug (at least since I started writing in it) has been just to add AutoFill based on the AddressBook Me record. I'm all for AutoComplete, but perhaps someone should branch out a new bug for it? If you do, please link it to this one, but not as any sort of requirement, they are two separate features.
Craeted bug 187454 (autocomplete) with proposed patch.
Blocks: 147975
I just tried Longship which contains the autofill patch and I must admit it's very handy. Innitially I was looking for the form autofill button or menu item like Safari v67 uses, but the way this patch works is even more elegent and usefull. Although I do think the various parts of this patch should at least be enabled or disabled via a preference (pane?). So we would be able to specify if we want to autofill/autocomplete from me/autocomplete from other data/all at the same time.
fixed last week. doing autocomplete is a separate issue. right now we do manual form fill from address book.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.