Re: [whatwg] Various autocomplete="" topics
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
> > > > 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)
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)
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 > > >