Bug 939351 (fx-autofill-backend)

Form Autofill form backend

NEW
Unassigned

Status

()

Toolkit
Form Autofill
5 years ago
6 months ago

People

(Reporter: Andy McKay, Unassigned)

Tracking

(Depends on: 5 bugs, Blocks: 1 bug, {meta})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 obsolete attachments)

Comment hidden (obsolete)
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

4 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.
Blocks: 990367
No longer depends on: 990367
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Summary: Implement requestAutoComplete → Implement requestAutocomplete backend
Comment hidden (obsolete)
Flags: sec-review?(dveditz)
Comment hidden (obsolete)

Updated

4 years ago
Blocks: 1018295
Summary: Implement requestAutocomplete backend → Implement initial requestAutocomplete backend

Updated

4 years ago
No longer blocks: 998077
Comment hidden (obsolete)

Comment 14

4 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.

Updated

4 years ago
Depends on: 1020440

Comment 15

4 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.

Updated

4 years ago
Depends on: 1020459

Updated

4 years ago
Depends on: 1020464

Updated

4 years ago
Depends on: 1020466

Updated

4 years ago
Depends on: 1020495

Updated

4 years ago
Depends on: 1020496

Comment 16

4 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

4 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 :-)
Depends on: 1020602
Depends on: 1020607
Depends on: 1020616
Depends on: 1020618
No longer blocks: 1018295
Duplicate of this bug: 1018295
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: 1018304
Keywords: meta
Product: Core → Toolkit
Summary: Implement initial requestAutocomplete backend → requestAutocomplete backend

Updated

4 years ago
Depends on: 1021060

Updated

4 years ago
Depends on: 1021172

Updated

4 years ago
Depends on: 1023484

Updated

4 years ago
Depends on: 1023813

Updated

4 years ago
Depends on: 1023862
Depends on: 1030295
Depends on: 1030301

Updated

4 years ago
Depends on: 1032762

Updated

4 years ago
No longer depends on: 1032762

Updated

4 years ago
Depends on: 1036481
Alias: rAc-backend → fx-autofill-backend
Status: ASSIGNED → NEW
Flags: sec-review?(dveditz)
Summary: requestAutocomplete backend → Form Autofill form backend
No longer depends on: 990200
No longer depends on: 990201
No longer depends on: 990203
No longer depends on: 990204
Depends on: 1333353
Depends on: 1109188
Component: Form Manager → Form Autofill
You need to log in before you can comment on or make changes to this bug.