W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2014

Re: [whatwg] Various autocomplete="" topics

From: Evan Stade <estade@chromium.org>
Date: Mon, 28 Apr 2014 11:42:53 -0700
Message-ID: <CAO4XGS_RNkMpkobGsXLvTd=AjxTWL5F=gJnxgXQPnZ_z8WbkMw@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
On Fri, Apr 25, 2014 at 4:54 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 3 Apr 2014, Mike West wrote:
> > On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > >
> > > > Also, consider the case of login forms without username fields. You
> > > > see this sort of thing a lot these days, when sites remember who was
> > > > last logged in:
> > > >
> > > > <form>
> > > > <label>Password for hober: <input type=password name=pw></label>
> > > > <p>Not hober? <a href=...>Click here to sign in</a>.
> > > > </form>
> > > >
> > > > It's difficult for tools to manage the user's auth info for such
> > > > pages. How can tools discover what the username is? The obvious
> > > > solution, in a world with autocomplete=username, would be to add
> > > > <input type=hidden autocomplete=username name=username value=hober>
> > > > to the form.
> > >
> > > So far, autocomplete="" hasn't applied to <input type=hidden>. This
> > > would be a bit weird, giving it a different meaning than usual
> > > (providing information to the UA, rather than getting information from
> > > the UA). I'm a bit skeptical of this kind of overloading.
> > >
> > > Not sure what the right solution is, though.
> >
> > As Garrett noted, this is already a solution Google is using, though not
> > with explicit syntax, just taking advantage of existing heuristics.
> > Paving this (potential) cowpath isn't really that weird.
> >
> > That said, an alternative might be to add a mechanism of associating
> > autocompletion metadata with the field in order to give the UA enough
> > context to fill it in. For example, if a password is being requested for
> > a known username, that username could be added as an new
> > "autocomplete-username" attribute (similar to the 'data-*' construct
> > HTML already supports):
> >
> >     <input type="password" autocomplete-username="hober">
>
> On Fri, 11 Apr 2014, Edward O'Connor wrote:
> >
> > It is kind of weird. Given that, maybe this case should have new syntax.
> > I'm OK with overloading autocomplete=username or with new syntax.
>
> I'm not sure I really understand how autocomplete-* would work (e.g. would
> you have to specify it for all three fields of a change-password form?).
>
> Having autocomplete="" mean something slightly different on type=hidden
> does make some sense, even if it is overloading. It has the advantage of
> fitting into the current syntax machinery, too.
>
> I've made a proposal in this bug:
>
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471
>
> I would be particularly interested in feedback from vendors who haven't
> commented on this yet. Will this overloading work for you?
>
>
> On Fri, 11 Apr 2014, Edward O'Connor wrote:
> > >
> > > I actually have a similar problem with purely JS-handled forms even
> > > unrelated to credentials. Because the form is never really submitted
> > > (even if we reuse the submit infrastructure, we cancel the 'submit'
> > > event and handle the work on the JS side), there's never an indication
> > > to the UA that it should save the fields, and so autofill never works
> > > right on these forms, even for things like postal addresses or e-mail
> > > addresses.
> > >
> > > For the pure JS case, an API (probably on the <form> itself) would
> > > make sense and seems relatively easy. I've filed a bug on this:
> > >
> > >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238
> >
> > This case is pretty weird. Authors are going out of their way to avoid
> > using the built in platform features that would get them autofill saving
> > for free. In some cases, they might be doing this precisely because they
> > want to prevent autofill but can't count on autocomplete=off anymore.
>
> I'm not sure what you mean here. The context is a form that is used in a
> purely scripted fashion. It's not at all obvious how to tell the user
> agent to save the data in this situation. I don't think authors are going
> out of their way to avoid using built-in platform features; what feature
> should they use here?
>
>
>
> On Fri, 11 Apr 2014, Edward O'Connor wrote:
> > >
> > > For the real submission case, I guess what we want is a way to say
> > > "autocomplete=off" after the fact, basically. An HTTP header seems
> > > like the most obvious solution.
> > >
> > >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239
> > >
> > > Again, these need multiple vendors on board to make progress.
> >
> > Browsers are moving away from respecting autocomplete=off. I don't think
> > we should be adding a new but basically equivalent mechanism.
>
> On Mon, 21 Apr 2014, Garrett Casto wrote:
> >
> > While I agree that it's a concern, I'm not overly worried that this is
> > going to be abused for a few reasons.
> >
> > 1) We talked to some major US banks when disabling autocomplete=off for
> > passwords, and though they historically have been a big proponent of the
> > feature they didn't seem bothered that it was no longer going to be
> > respected. It seems like sites are more accepting of password managers
> > now. I wouldn't be surprised if a reasonable percentage of
> > autocomplete=off usage is just inertia at this point.
> >
> > 2) A well-intentioned site might use autocomplete=off thinking that it's
> > a security benefit to their site. Doing this with this new API would be
> > obvious abuse and it doesn't seem likely that a site would do it unless
> > they were looking for some way to block password managers. 3) If a site
> > really wants to go out of their way to make sure that password managers
> > don't work on their site, there are already ways of doing it. This would
> > be an easier mechanism, but I'm not sure how much that matters.
> >
> > If we still think that this is too likely to be abused, another
> > possibility might be to only allow the site to assert login succeeded
> > not that it failed. Not sure how useful that is though, since it's
> > generally easier to prompt on incorrect login than miss a correct login.
>
> I think the way to make progress on this issue would be for the vendors
> interested in deploying a solution to do so experimentally, and to see how
> authors use it.
>
>
> On Mon, 14 Apr 2014, Dan Beam wrote:
> >
> > I propose requestAutocomplete()[1] should return a Promise.  This has
> > been requested since the creation of this API[2][3] and seems like a
> > natural fit.  Web authors can then call requestAutocomplete() like this:
> >
> >   form.requestAutocomplete().then(function() {
> >     // form.submit() or some other success action
> >   }, function(errorDetails) {
> >     // handle error based on errorDetails.reason (e.g. "cancel")
> >   });
> >
> > The returned promise would be resolved after the corresponding
> > "autocomplete" or "autocompleteerror" event is dispatched on the form.
> > [...]
>
> Fine by me.
>
> How stable is the whole promise world so far? Are any APIs using it yet?
>
> I tried using it in HTML before, but the API changed radically shortly
> afterwards, so I'm a bit reluctant to start specifying stuff again on this
> topic before other specs have done so.
>
>
> On Thu, 24 Apr 2014, Dan Beam wrote:
> >
> > Regarding the rejection argument: requestAutocomplete() can fail in a
> > way that doesn't map intuitively to the current DOMException names (e.g.
> > the invoking <form> has autocomplete="off" or isn't in a frame).
> > Adding new names for these specific failure categories doesn't seem
> > useful to the platform.  Additionally, many potential failure causes may
> > have the same reason property[1] ("disabled" => SecurityError,
> > WrongDocumentError?, InvalidAccessError?)** and the terminology differs
> > slightly ("cancel" => AbortError).
> >
> > This seems confusing to web authors, so I propose a new type instead (in
> > IDL):
> >
> >  interface AutocompleteError : DOMException {
> >      readonly attribute DOMString reason;  // matches
> AutocompleteErrorEvent's reason
> >  };
>
> On Fri, 25 Apr 2014, Boris Zbarsky wrote:
> >
> > In general, please check with public-script-coord before minting new
> > exception types; there's been a lot of discussion on that issue
> > recently.
>
> Please report back on the conclusion of this discussion on this bug:
>
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472
>
> Thanks!
>
>
> On Wed, 23 Apr 2014, Brian Nicholson wrote:
> > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote:
> > >
> > > Currently, requestAutocomplete lets a user agent provide the same user
> > > experience across multiple sites for common data input flows. A site
> > > describes the data it desires (via a form and autocomplete
> > > attributes), and the user agent uses this information and what it
> > > knows about the user to expedite data input. For example, if one of
> > > the form elements has autocomplete=”cc-number” the browser might
> > > provide an experience tailored for a payment flow, or if there’s an
> > > element with autocomplete=”bday” the browser might use an experience
> > > that’s tailored for sharing identiy.
> > >
> > > We’ve found that there are some details of the interaction which might
> > > affect the UX which cannot be inferred from the data inputs. We
> > > propose to add an optional argument to the requestAutocomplete method.
> > > Thus invocation would look like:
> > >
> > >     form_element.requestAutocomplete(details);
> > >
> > > This |details| argument would be an object where key-value pairs
> > > provide additional details regarding the request. The spec should
> > > define a set of keys and associated data types which are recognized.
> > > There are currently two key-value pairs we would like to add:
> > >
> > >     key: “transactionAmount”
> > >     value: number
> > >     description: For data that is going to be applied towards a
> > > transaction, the /maximum/ value of the transaction. The browser does
> > > not guarantee that the returned payment instrument will work, but
> > > keeping the transaction under this amount will increase the likelihood
> > > of receiving a valid card number.
> > >
> > >     key: “transactionCurrency”
> > >     value: string
> > >     description: a valid ISO 4217 currency code that describes the
> > > currency for transactionAmount. If not provided, the default is “USD”.
> > >
> > > Justification? There are upper bounds on certain payment instruments,
> > > for example different credit cards have different credit limits; a
> > > debit card is linked to a bank account with a certain balance. It’s a
> > > much preferable user experience to be able to catch these problems
> > > earlier rather than waiting for the merchant to attempt the
> > > transaction and have it fail (or have a user’s account overdrawn).
> > > Concretely, Chromium wants to handle transactions over $2000
> > > differently from transactions under that amount.
> >
> > This optional argument sounds reasonable to me (FWIW, I'm working on the
> > requestAutocomplete implementation for Firefox). The transaction fields
> > also seem sensible, but I have no experience with payment APIs, so I
> > can't give feedback on how well this will work with payment providers in
> > general (and whether any additional fields might be useful). Those
> > working on Mozilla's payment APIs are aware of this thread, so hopefully
> > they'll be giving feedback if they have anything to add.
>
> On Thu, 24 Apr 2014, Evan Stade wrote:
> > Ian wrote:
> > > Why would this only apply to requestAutocomplete()? Surely it would be
> > > just as important for the case where the user agent is filling in a
> > > form without using that API.
> >
> > That is true, but I don't know of a better way to convey this
> > information from the page to browser. Additional attributes on the
> > cc-number field?
>
> Well, if we're going to use type=hidden fields to expose the username, we
> could also use it to expose the amount and currency. Would that work?
>

I agree with those upthread who said that overloading autocomplete= to
provide information to the user agent is confusing. If we introduce
something like autocomplete="transaction-currency" then it's easy to
misinterpret that as the site asking the browser what the currency is for
the payment method, then having a site author use transaction-currency in a
non type=hidden input.

So I would prefer a separate attribute called autocomplete-hint="" or
something, which has its own set of tags.

(also added this comment to the bug)


>
>
> On Thu, 3 Apr 2014, Andy Mabbett wrote:
> >
> > Why would you define any address components other than those in vCard, a
> > standard with massive implementation and interoperable with most address
> > book applications and services?
>
> Because vCard doesn't work in China.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Monday, 28 April 2014 18:44:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC