- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 25 Apr 2014 23:54:53 +0000 (UTC)
- To: whatwg@whatwg.org
- Message-ID: <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com>
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?
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 Friday, 25 April 2014 23:59:16 UTC