Open
Bug 939351
(fx-autofill-backend)
Opened 11 years ago
Updated 2 years ago
[meta] Form Autofill form backend
Categories
(Toolkit :: Form Autofill, defect)
Toolkit
Form Autofill
Tracking
()
NEW
People
(Reporter: andy+bugzilla, Unassigned)
References
(Depends on 3 open bugs, Blocks 1 open bug)
Details
(Keywords: meta)
Attachments
(2 obsolete files)
Comment hidden (obsolete) |
Updated•11 years ago
|
Blocks: rAc-android
Comment 1•11 years ago
|
||
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
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 5•11 years ago
|
||
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.
Updated•11 years ago
|
Depends on: rAc-desktop
Updated•11 years ago
|
Blocks: rAc-desktop
No longer depends on: rAc-desktop
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•11 years ago
|
Summary: Implement requestAutoComplete → Implement requestAutocomplete backend
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•11 years ago
|
Flags: sec-review?(dveditz)
Comment hidden (obsolete) |
Updated•10 years ago
|
Summary: Implement requestAutocomplete backend → Implement initial requestAutocomplete backend
Updated•10 years ago
|
No longer blocks: rAc-desktop
Comment hidden (obsolete) |
Comment 14•10 years ago
|
||
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.
Comment 15•10 years ago
|
||
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.
Comment 16•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
(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 :-)
Comment 19•10 years ago
|
||
This bug is becoming a meta bug for the backend work which was split up.
Alias: rAc-backend
Assignee: bnicholson → nobody
Component: DOM → Form Manager
Depends on: autofill-profile-storage
Keywords: meta
Product: Core → Toolkit
Updated•10 years ago
|
Attachment #8433082 -
Attachment is obsolete: true
Updated•10 years ago
|
Updated•10 years ago
|
Summary: Implement initial requestAutocomplete backend → requestAutocomplete backend
Updated•8 years ago
|
Alias: rAc-backend → fx-autofill-backend
Status: ASSIGNED → NEW
Flags: sec-review?(dveditz)
Summary: requestAutocomplete backend → Form Autofill form backend
Updated•8 years ago
|
Blocks: fx-form-autofill
Updated•7 years ago
|
Component: Form Manager → Form Autofill
Updated•2 years ago
|
Severity: normal → S3
Updated•2 years ago
|
Summary: Form Autofill form backend → [meta] Form Autofill form backend
You need to log in
before you can comment on or make changes to this bug.