Open Bug 939351 (fx-autofill-backend) Opened 7 years ago Updated 3 years ago
Form Autofill form backend
http://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ writ large, in Google-colored neon letters against the night sky.
OS: Mac OS X → All
Hardware: x86 → All
On the Chrome side, we're hard at work on internationalizing our dialog, such that the set of fields it can fill in is expanded. For example, we're adding support to fill in arbitrarily many address lines via street-address, and other fields like dependent locality (CEDEX), etc. are on the way. We more or less* plan to support the complete set of address-related fields in the autocomplete spec. Over the past Summer we attempted to improve i18n support in that spec with Ian Hixie's help. If there are further improvements necessary, please suggest them! As far as the requestAutocomplete spec, that's here: <http://wiki.whatwg.org/wiki/RequestAutocomplete>. It really is quite short, and that's by design: requestAutocomplete is meant to be generally useful for any autocomplete type. It's just that Chrome's current use case is payments, and for now, that's all we have concrete plans to support. But you could imagine it being useful for other common web forms, and we wouldn't want to head that off at the spec level. *what do I mean by more or less? Well, for example, it's hard to support first-name and last-name and also full-name, because both tokenizing names and concatenating names is hard, so unless we ask the users for their names twice, we don't see an easy way forward. So we've settled on full-name only for now. Generally though, we want to support as much of the address portion of the autocomplete spec as we can, and which makes sense in a payment-on-the-web context.
Summary: Implement requestAutoComplete → Implement requestAutocomplete backend
Summary: Implement requestAutocomplete backend → Implement initial requestAutocomplete backend
Following up to the meeting we held yesterday, I'm about to file the individual bugs into which we determined we could break down the back-end implementation. They'll be dependencies of this bug, and also of bug 1018317 which is the Firefox Desktop tracking bug about the work needed to reach a minimal version that can work on a demo website (but is far from being complete). I'll also try to guess some "point estimates" for them, mainly for tracking purposes in the Desktop backlog process, and add them to the Desktop backlog for tracking, even though they are platform bugs and will probably be worked on by different teams. Please let me know if they make sense to you, note that we can also file other bugs while we work, and determine whether they block bug 1018317 or not.
Brian, in particular I think bug 1020440 is already actionable by separating a very small subset of this patch, even without the implementation and UI glue. Also, probably that bug is the only one requiring a DOM peer review before we start. Note that we will definitely need a more detailed DOM-level review later in the process, before we release. I filed bug 1020443 for that.
I filed various bugs, but none for the actual core of the implementation yet. Feel free to add those if you already have an idea, we can also discuss the plan in our next meeting.
(In reply to :Paolo Amadini from comment #16) > I filed various bugs, but none for the actual core of the implementation yet. In other words (for those who know about the Desktop estimation system), we already have 33 "points" worth of back-end work on the table, and none for the actual core of the feature :-)
This bug is becoming a meta bug for the backend work which was split up.
Summary: Implement initial requestAutocomplete backend → requestAutocomplete backend
Alias: rAc-backend → fx-autofill-backend
Status: ASSIGNED → NEW
Summary: requestAutocomplete backend → Form Autofill form backend
You need to log in before you can comment on or make changes to this bug.