Re: [whatwg] Various autocomplete="" topics

2014-05-16 Thread Garrett Casto
On Mon, May 5, 2014 at 10:38 PM, Matthew Noorenberghe <
mattn+wha...@mozilla.com> wrote:

> On Fri, Apr 11, 2014 at 3:36 PM, 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.
>
> In Firefox, we save the form values after validation but before the
> submit event is dispatched to content. This way we successfully save
> the form fields in form history when a script is handling the actual
> submission. This also helps against sites who try to manipulate the
> form fields upon submission to avoid having them saved (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been
> doing this for a long time and I don't recall any complaints as long
> as I've been working on password and form manager for Firefox (since
> 2009).
>
> There are many websites that use click handlers on buttons outside
> forms instead of using form submission and those fields don't get
> saved in Firefox. I suspect web developers don't realize that they are
> losing out on form history and other benefits like being able to
> submit the form with the Enter key from a text input. I don't see
> sites that are not having their fields saved by not using form
> submission switching to calling a new API when they can instead use an
> onsubmit handler which has other benefits. Given that Firefox already
> saves values with preventDefault inside form submit handlers and click
> handlers on submit buttons, and the other benefits of sites using form
> submission, I don't think a new API is needed.
>

The problem right now is that there are two legitimate reasons that a site
may return false from the submit handler, either because the submission
failed validation in some way or because submission is being handled via
script. Browsers can either ignore this distinction (e.g. Firefox) or try
and separate the two heuristically (e.g. Chrome). Both are reasonable
approaches given the current state of the world, but neither are ideal. We
should allow sites to make this distinction.

I agree that we shouldn't necessarily add contortions for sites that don't
use form submission, but currently there isn't a right way to do this even
if the site wants to.


> > > For the pure JS case, an API (probably on the  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.
>
> It seems like more evangelism is needed to let authors know that
> preventDefault inside a form submission handler is the better way to
> handle forms where navigation isn't wanted. The benefits are: form
> history, password management, better UX (allowing submission via
>  when inputs are in a ), and possibly better
> accessibility(?).
>
> I've been thinking about cases where we could detect the pattern of
> fake forms (using text s and s with click handlers
> together without a ) and provide notices in developer tools to
> help evangelize but it's looking to be tricky.
>
> --
> Matthew Noorenberghe
>


Re: [whatwg] Various autocomplete="" topics

2014-04-21 Thread Garrett Casto
>
>
> > 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.
>
>
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 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  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.
>
>
In most of the cases that I've seen where this comes up (e.g. Pandora) it
seems like the entire site does navigation via AJAX + history.pushState().
It doesn't seem like the site is trying to avoid password managers so much
as they are trying to keep the aesthetic of their site consistent.


> > The requestAutocomplete() API is a Chrome proprietary feature right
> > now so it's sort of acadmic, but:
> >
> > 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.
>
> Agreed. I don't see the benefit of requestAutocomplete() here.
>
>
> Ted
>


Re: [whatwg] new autocomplete="" values for authentication forms (was Re: Autocomplete and autofill features and feedback thereon)

2014-03-28 Thread Garrett Casto
Any comments on this? I'm not sure where this fits in Safari's timeline,
but it's reasonably high up on Chrome's priority list.


On Fri, Mar 7, 2014 at 4:34 PM, Garrett Casto  wrote:

> I've been meaning to suggest this for a while now, but just haven't gotten
> around to it. Chrome would be definitely implement autofill attributes
> along these lines. I'm relatively indifferent to the exact syntax.
>
> Another related issue that would be nice to address would be allowing
> sites to positively assert that authentication succeeded. For sites that
> authenticate client side via XHR, standardizing something like
> window.external.AutoCompleteSaveForm() would be very helpful. For sites
> that validate server side, I'm less sure what the correct avenue to convey
> this information would be (response code, header, ...). I'm assuming that
> this will be more contentious than adding username and password attribution
> and I don't want to hold that up, but I would like to see opinions on this.
>
>
> On Thu, Mar 6, 2014 at 11:54 PM, Jake Archibald wrote:
>
>> I like this, also provides hooks for something like
>> form.requestAutocomplete to do one-click account creation, along with
>> password generation.
>>
>
> Eventually doing something like requestAutocomplete for account creation
> would be nice, but there are other issues that we would need to solve
> first. For instance, most signup flows include a CAPTCHA and options to
> e.g. receive email.
>
>
>> On 5 Mar 2014 20:39, "Edward O'Connor"  wrote:
>>
>> > Hi,
>> >
>> > Ian wrote, in 2012:
>> >
>> > >> This might fall under the broader class of "identity"-related fields,
>> > >> which I think merit their own carefully thought out set of tokens.
>> > >> There was some work done on the beginnings of such a specification --
>> > >> see https://wiki.mozilla.org/Identity-inputs -- but my current
>> > >> understanding is that this is an area in need of further development.
>> > >
>> > > I'm happy to add more things like this to the spec, but I don't know
>> > > what to add exactly. If there is a concrete description of what fields
>> > > I should add here, I'd be happy to do so.
>> >
>> > The techniques browsers use for autofilling auth information would
>> > benefit enormously from some additional autocomplete="" values. The wiki
>> > page Ilya mentioned captures the use cases pretty well. I think these
>> > are the critical ones that capture the most common cases:
>> >
>> > # Passwords
>> >
>> > On "change your password" forms, which  is your
>> > current password? Which is the new password? Browsers want to avoid
>> > filling the old password into the new or confirm password fields.
>> > Additionally, distinguishing such fields would help tools that generate
>> > passwords. These are useful on both sign-up and change password forms.
>> >
>> >   - your current password
>> >  - a new password
>> >  - the new password, again
>> >
>> > Next to the other autocomplete values, "new" and "confirm" don't look
>> > descriptive enough. "new-password" and "confirm-password", maybe?
>> > "" feels redundant and
>> > verbose to me.
>> >
>> > # Usernames
>> >
>> > Lots of websites use email addresses as usernames. Tools should be able
>> > to distinguish email-used-as-username fields from other email fields.
>> > This can also help on "forgot password"/"forgot username" forms.
>> >
>> >   - your username on this site
>> >- your preferred email address
>> >  - your username on this site,
>> >not your preferred email
>> >address
>> >- OpenID
>> >
>> > 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:
>> >
>> > 
>> > Password for hober: 
>> > Not hober? Click here to sign in.
>> > 
>> >
>> > 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 > > autocomplete=username name=username value=hober> to the form.
>> >
>>
>
> The Google login pages recently changed to work like this. To continue
> working with Chrome, we had them add a  class=hidden> field. I agree that it would be better if you could just use
> type=hidden instead of having to manually hide the field though.
>
>
>> > Thoughts?
>> >
>> >
>> > Ted
>> >
>>
>
>


Re: [whatwg] new autocomplete="" values for authentication forms (was Re: Autocomplete and autofill features and feedback thereon)

2014-03-07 Thread Garrett Casto
I've been meaning to suggest this for a while now, but just haven't gotten
around to it. Chrome would be definitely implement autofill attributes
along these lines. I'm relatively indifferent to the exact syntax.

Another related issue that would be nice to address would be allowing sites
to positively assert that authentication succeeded. For sites that
authenticate client side via XHR, standardizing something like
window.external.AutoCompleteSaveForm() would be very helpful. For sites
that validate server side, I'm less sure what the correct avenue to convey
this information would be (response code, header, ...). I'm assuming that
this will be more contentious than adding username and password attribution
and I don't want to hold that up, but I would like to see opinions on this.


On Thu, Mar 6, 2014 at 11:54 PM, Jake Archibald wrote:

> I like this, also provides hooks for something like
> form.requestAutocomplete to do one-click account creation, along with
> password generation.
>

Eventually doing something like requestAutocomplete for account creation
would be nice, but there are other issues that we would need to solve
first. For instance, most signup flows include a CAPTCHA and options to
e.g. receive email.


> On 5 Mar 2014 20:39, "Edward O'Connor"  wrote:
>
> > Hi,
> >
> > Ian wrote, in 2012:
> >
> > >> This might fall under the broader class of "identity"-related fields,
> > >> which I think merit their own carefully thought out set of tokens.
> > >> There was some work done on the beginnings of such a specification --
> > >> see https://wiki.mozilla.org/Identity-inputs -- but my current
> > >> understanding is that this is an area in need of further development.
> > >
> > > I'm happy to add more things like this to the spec, but I don't know
> > > what to add exactly. If there is a concrete description of what fields
> > > I should add here, I'd be happy to do so.
> >
> > The techniques browsers use for autofilling auth information would
> > benefit enormously from some additional autocomplete="" values. The wiki
> > page Ilya mentioned captures the use cases pretty well. I think these
> > are the critical ones that capture the most common cases:
> >
> > # Passwords
> >
> > On "change your password" forms, which  is your
> > current password? Which is the new password? Browsers want to avoid
> > filling the old password into the new or confirm password fields.
> > Additionally, distinguishing such fields would help tools that generate
> > passwords. These are useful on both sign-up and change password forms.
> >
> >   - your current password
> >  - a new password
> >  - the new password, again
> >
> > Next to the other autocomplete values, "new" and "confirm" don't look
> > descriptive enough. "new-password" and "confirm-password", maybe?
> > "" feels redundant and
> > verbose to me.
> >
> > # Usernames
> >
> > Lots of websites use email addresses as usernames. Tools should be able
> > to distinguish email-used-as-username fields from other email fields.
> > This can also help on "forgot password"/"forgot username" forms.
> >
> >   - your username on this site
> >- your preferred email address
> >  - your username on this site,
> >not your preferred email
> >address
> >- OpenID
> >
> > 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:
> >
> > 
> > Password for hober: 
> > Not hober? Click here to sign in.
> > 
> >
> > 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  > autocomplete=username name=username value=hober> to the form.
> >
>

The Google login pages recently changed to work like this. To continue
working with Chrome, we had them add a  field. I agree that it would be better if you could just use
type=hidden instead of having to manually hide the field though.


> > Thoughts?
> >
> >
> > Ted
> >
>