[whatwg] Autocomplete and autofill features and feedback thereon

[Dan Beam]

On Wed, Nov 21, 2012 at 3:55 PM, Ilya Sherman <isherman at chromium.org> wrote:
> On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Tue, 16 Oct 2012, Ilya Sherman wrote:
>> > The payment instrument type is almost certainly appropriate to add -- it
>> > is included on almost every website that I've encountered that includes
>> > payment card fields.  It was an oversight on my part to omit it from the
>> > initial proposal.
>>
>> It's redundant data, the credit card number itself says what type it is.
>>
>> More importantly, I don't know how to store the information. What values
>> should we be expecting here? If a site has radio buttons "v", "m" and "a",
>> and another has a <select> with "4", "5", and "3", and yet another has
>> three buttons which set a type=hidden with the values "visa", "mastercard"
>> and "amex", how is the user agent to figure out what's going on? This
>> makes the magic needed around dates look positively easy.
>>
>
> I agree that it's redundant data, but many websites ask for it separately
> anyway.  One common reason for this is that the website only supports a
> subset of all possible credit card issuers -- for example, many do not
> support DiscoverCard.  While the site *could* theoretically infer from the
> entered card number that the card is not supported, and show the user an
> error, most sites instead force the user to select the card type, and
> inform the user of unsupported card types by omitting them from the list.
>
> Regarding storing of the data: I think being able to fill the data is more
> important than being able to store it.  For example, Chrome stores just the
> card number, and not the type; but Chrome supports filling the type by
> inferring it from the stored card number.  For filling the card type, I
> think it's strictly easier than filling a <select> dropdown containing
> country names, since localization issues don't come into play as much.  The
> user agent is presumably not going to be able to handle *every* case; but
> in my experience, it's not too hard to handle many/most of the real-world
> cases.  Since this attribute is used just as a hint, esoteric difficult
> cases don't seem like enough reason to omit the card type as a known token
> in the spec.
>
>
>> > Finally, I have gotten a request to include a field type for bank
>> > account numbers, though I have only seen this info actually requested on
>> > a small handful of extremely prominent (and generally trusted) websites:
>> > Amazon, PayPal, and I think Google Wallet.
>>
>> Is there any reason we shouldn't just treat bank accounts like just
>> another credit card, and use cc-number for these?
>>
>
> Yes: Most websites that support credit card numbers as inputs do not
> support bank account numbers.  The few websites that do support bank
> account numbers use separate fields for these vs. credit card number
> inputs.  Labeling both fields identically would leave the browser unable to
> distinguish which field to fill with what info.
>
>
>> On Wed, 31 Oct 2012, Dan Beam wrote:
>> >
>> > The experimental implementation [1] has been updated to dispatch an
>> > "autocompleteerror" as per convention/your feedback.
>>
>> "autocompleteerror" seems like it'd be fired for an error, not user
>> cancelation. User cancelation is usually called either "abort" or
>> "cancel". I think autocompletecancel is fine. It's consistent with
>> oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a
>> slightly different case, based on what the spec says.)
>>
>
> There are also cases where we'd want to return actual errors.  For example,
> in Chrome, we are only planning to support this dialog for sites served
> over HTTPS and without security errors.  We might also want to fire an
> error in case the input fails to pass the form's validation requirements.
>  Should we use autocompleteerror for the errors, and autocompletecancel for
> user cancelations?  Firing separate events for cancelations vs. errors
> forces developers to check for each of these cases separately, which seems
> like a less convenient API than just checking for one sort of failure
> event.  Perhaps we should have a single event named something like
> autocompletefail or something like that?

I don't particularly care about the naming (fail vs. error), I just
knew we had a pre-existing *error event and agreed with Anne that I
might as well go with the convention (of 1).  I can change it quite
easily to whatever the consensus is.

I definitely agree to a single event.  It would be great to do this
and give enumerable failure reasons (if this is deemed secure enough).
 An example:

  enum ErrorCause {
    FROM_FRAME,
    NEEDS_GESTURE,
    NOT_SECURE,
  };

This could be a property on the event (event.cause, event.reason?)
argument passed to the error event (kind of like DOM exceptions).
This seems akin to event.property in CSS transition end events (and
disputably many other examples).