On Thu, 3 Apr 2014, Mike West wrote:
> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <i...@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:


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:



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?

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.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to