Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Wed, Dec 3, 2014 at 12:26 PM, Igor Minar wrote: > In FF 34 the form autofill works well but > password autofill doesn't fire any events. Do you have a testcase demonstrating this problem? Based on my knowledge of Firefox code, I am surprised that there would be a difference between password and form autofill. (Feel free to follow up directly rather than on the list.) Gavin
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
Just to follow up on this for archival purposes... In Chrome M40 (possible even sooner) the proper input and change events are triggered for both form and password autofill. Good job guys! Safari 7 and 8 are still broken. In FF 34 the form autofill works well but password autofill doesn't fire any events. Things are still pretty broken for many end users but we've already made major progress. Yay! \i On Fri Nov 14 2014 at 8:12:33 AM Igor Minar wrote: > I believe so, but I'll double check and will email you off this thread. > > \i > > > On Thu Nov 13 2014 at 11:06:37 PM Evan Stade wrote: > >> That sounds like crbug.com/354257 which was fixed in March. Are you sure >> this is still a problem on newer versions of Chrome? >> >> On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar wrote: >> >>> Are you going to properly fire change&input events when autofill happens? >>> >>> The current autofill behavior is causing major headaches for application >>> and framework developers and by ignoring autocomplete attribute you disable >>> the only way developers can work around this bug. >>> >>> On angular we had to developer a special hack in an attempt to fix it, >>> but it's far from ideal: https://github.com/angular/angular.js/issues/ >>> 1460#issuecomment-33837127 >>> >>> The browser should let DOM know when autofill happens, so apps can treat >>> user input and autofill as the same. Right now this is not the case and it >>> sounds like you are going to make it only worse. >>> >>> \i >>> >>> >>> >>> On Thu Nov 13 2014 at 11:20:28 AM Evan Stade >>> wrote: >>> Hi, Chrome already ignores the prevalent autocomplete="off" for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete="off" will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete="off" for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete="off" for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete="off" in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I am curious what other browsers do around autocomplete="off", and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade >>> >>
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 19:10, Evan Stade wrote: The problem is that we don't think autocomplete="off" is used judiciously. Could you make a compromise and respect autocomplete="off" for only type="text", and ignore autocomplete="off" for all other input types as you guys planned? And then look at how the web reacts to autocomplete="off" being ignored for the other types before deciding on how to handle it for type="text"? I know you can risk end up with bad web designers making all inputs of type="text" instead of using the proper types like a good web designer would (or should). But for the end user that would be better than textarea "hacks" or other weird things to "clear" or ignore things or fully custom inputs. If the results (I'll assume the web will be watched to see how the reaction is to such changes right?) are positive and web designers actually do it correctly and do not try to hack or change the type of inputs to text en masse, then type="text" would work fine forward as a input type for text that changes so frequently that any autofill or autocomplete would make no sense/be a waste of resources. Regards, Roger. -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 11:42 PM, Roger Hågensen wrote: > On 2014-11-14 08:02, Evan Stade wrote: > >> On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen >> wrote: >> >> On 2014-11-13 20:20, Evan Stade wrote: >>> >>> Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I don't like that browsers ignore HTML functionality hints like that. >>> >>> I have one real live use case that would be affected by this. >>> http://player.gridstream.org/request/ >>> This radio song request uses autocomplete="off" for the music request >>> because a listener would probably not request the same bunch of songs >>> over >>> and over. >>> >>> autocomplete="off" will still be respected for autocomplete data. This >> should cover your use case. >> >> >> Also, banks generally prefer to have autocomplete="off" for credit card >>> numbers, names, addresses etc. for security reasons. And that is now to >>> be >>> ignored? >>> >>> I'm not sure what security threat is addressed by respecting >> autocomplete="off". >> > > SSN, PIN, and so on. > Sure, it's the users responsibility to ensure their PC/laptop/tablet is > secured. > But it's very quick to press 0-9 and you got a pin, that being said a bank > should have two factor anyway (or better), and pins can be changed. SSN > can not though. Also the government is pretty strict in Norway on the > leaking of SSN (here's it called Personal Number though) and in that case > they start with 0-9 so it's quick to get the autocomplete to spit it out. > > This is also autocomplete, not Autofill (in Chrome parlance). >> > > In that case, my mistake, autocomplete, autofill, autosuggest, input > history, it all kind of blurs together, so apologies for that. > > Would there be any point in having a per FORM autofill on/off instead? > autocomplete="off" can already be applied to a form as well as an input > That way if a autofill="off" is set for the form itself then the user > could be prompted "This site wishes to not store any form data, Agree? Yes! > No" and then have the browser remember the choice the user made (so the > next time based on the user choice, the form is either autofilled or not). > and maybe word it better than I did there. > And if the autofill="off" hint is missing (or set to "on") then the user > is never prompted. > > This would give even more power to the user than currently. The problem is that we don't think autocomplete="off" is used judiciously. There's no particular correlation with risk to the user. The user is not going to be able to make an informed choice in response to that prompt, and it's added friction. > > If it was my bank I would probably (if shown such a prompt) prefer to not > have anything autofilled or autocompleted. > But if it was a comment form on a blog I'd probably want that (autofilled > and/or autocomplete etc). > As a user I should be able to choose that easily. (digging around in > advanced settings is not what I'd call easy.) > The key though is it defaults to autofill and the user prompt only appears > if autofill="off" is set as a parameter for the form, and the user choice > is remembered. > > Geolocation data is prompted for in a similar way as to what I describe > here right? Chrome Autofill already prompts the user in the form of a dropdown. If the user doesn't want to share information with the site, they shouldn't select one of the rows in the dropdown. A second prompt is not going to add value. > > > > -- > Roger "Rescator" Hågensen. > Freelancer - http://www.EmSai.net/ > >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
I believe so, but I'll double check and will email you off this thread. \i On Thu Nov 13 2014 at 11:06:37 PM Evan Stade wrote: > That sounds like crbug.com/354257 which was fixed in March. Are you sure > this is still a problem on newer versions of Chrome? > > On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar wrote: > >> Are you going to properly fire change&input events when autofill happens? >> >> The current autofill behavior is causing major headaches for application >> and framework developers and by ignoring autocomplete attribute you disable >> the only way developers can work around this bug. >> >> On angular we had to developer a special hack in an attempt to fix it, >> but it's far from ideal: >> https://github.com/angular/angular.js/issues/1460#issuecomment-33837127 >> >> The browser should let DOM know when autofill happens, so apps can treat >> user input and autofill as the same. Right now this is not the case and it >> sounds like you are going to make it only worse. >> >> \i >> >> >> >> On Thu Nov 13 2014 at 11:20:28 AM Evan Stade wrote: >> >>> Hi, >>> >>> Chrome already ignores the prevalent autocomplete="off" for password >>> fields. We plan to ignore this tag for Autofill (addresses, credit cards) >>> fields as well. autocomplete="off" will still be respected for >>> autocomplete >>> data (e.g. past searches on crbug.com). >>> >>> We think this will break a very small number of sites that use >>> autocomplete="off" for legitimate reasons, e.g. they use the Google Maps >>> Places Autocomplete API, and don't want Chrome trying to autofill in >>> addition. But it will improve behavior for a much larger set of sites >>> which >>> use autocomplete="off" for confused reasons as a part of, e.g., their >>> checkout flow. We have found the prevalence of autocomplete="off" in top >>> sites' checkout forms to be quite high. >>> >>> Currently this new behavior is available behind a flag. We will soon be >>> inverting the flag, so you have to opt into respecting >>> autocomplete="off". >>> >>> I am curious what other browsers do around autocomplete="off", and if >>> they >>> respect it for address/user profile/credit card type data. Since there's >>> no >>> way to feature detect the browser's behavior, it would be convenient if >>> all >>> browsers agreed on the meaning/value of the attribute. >>> >>> -- Evan Stade >>> >> >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 08:02, Evan Stade wrote: On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen wrote: On 2014-11-13 20:20, Evan Stade wrote: Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I don't like that browsers ignore HTML functionality hints like that. I have one real live use case that would be affected by this. http://player.gridstream.org/request/ This radio song request uses autocomplete="off" for the music request because a listener would probably not request the same bunch of songs over and over. autocomplete="off" will still be respected for autocomplete data. This should cover your use case. Also, banks generally prefer to have autocomplete="off" for credit card numbers, names, addresses etc. for security reasons. And that is now to be ignored? I'm not sure what security threat is addressed by respecting autocomplete="off". SSN, PIN, and so on. Sure, it's the users responsibility to ensure their PC/laptop/tablet is secured. But it's very quick to press 0-9 and you got a pin, that being said a bank should have two factor anyway (or better), and pins can be changed. SSN can not though. Also the government is pretty strict in Norway on the leaking of SSN (here's it called Personal Number though) and in that case they start with 0-9 so it's quick to get the autocomplete to spit it out. This is also autocomplete, not Autofill (in Chrome parlance). In that case, my mistake, autocomplete, autofill, autosuggest, input history, it all kind of blurs together, so apologies for that. Would there be any point in having a per FORM autofill on/off instead? That way if a autofill="off" is set for the form itself then the user could be prompted "This site wishes to not store any form data, Agree? Yes! No" and then have the browser remember the choice the user made (so the next time based on the user choice, the form is either autofilled or not). and maybe word it better than I did there. And if the autofill="off" hint is missing (or set to "on") then the user is never prompted. This would give even more power to the user than currently. If it was my bank I would probably (if shown such a prompt) prefer to not have anything autofilled or autocompleted. But if it was a comment form on a blog I'd probably want that (autofilled and/or autocomplete etc). As a user I should be able to choose that easily. (digging around in advanced settings is not what I'd call easy.) The key though is it defaults to autofill and the user prompt only appears if autofill="off" is set as a parameter for the form, and the user choice is remembered. Geolocation data is prompted for in a similar way as to what I describe here right? -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-13 20:20, Evan Stade wrote: Chrome already ignores the prevalent autocomplete="off" for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete="off" will still be respected for autocomplete data (e.g. past searches on crbug.com). What about repetitive entries of varied data? Example: An accountant entering names, addresses and telephone numbers into a database. In this case the suggestions may just be a nuisance as you are entering a ton of varied information and unless they are all named John Smith the autocomplete is pretty useless. Take an amount of 1463.57 now does that really need to be stored in the autocomplete list? A medical assistant entering information into various fields. In this case a autocomplete should probably not be shown for decency sake as the last thing you want is "Rape" being suggested when you are trying to type "Rhythmic Arrhythmia" (tasteless example I know but in theory somethig similar could happen). These people may log in then log out and somebody else sits down. You might say that it's up to the admin to ensure the machine is set up properly to not autocomplete anything, but what if it's not? At least a Web App mitigate some of this issue or provide autocomplete on the majority of input fields except a select few and so on. Now I could care less what the default is for any of these on or off is fine, but the key is that they can be set to be on or off. In a web app this may be preferable as a setting in the web apps preferences page. This is thinking of single user only. If browser user profiles are ever added then this may no longer be a issue (as any autocomplete would then follow the users), this also fits into the whole "The browser as a OS" idea. When a major framework ads a workaround for some fields to have autocomplete disabled the others will follow and suddenly nobody are using type="email" and similar, they'll all be using textarea with style set to resize none and height 1em and various ways to deal with pressing enter and different ways of submitting the form. I'd rather not have to deal with that as either a user nor a developer. When I set up HTML contact forms I always leave the default (i.e. I do not define autocomplete at all) thus respecting the user's wishes (hopefully). As a developer I can easily change the cone I'm working on to do whatever I want, but as a user I can't change the code of other sites. Remember "Do Not Track"? I loved that idea, but IE enforced it by default and now it's just useless, even though it's set in my browser I've yet to see a single site respect it. Would that have been the case if it had not been forced by default? I've no idea. But I know there is always a cause and effect. I think ignoring autocomplete="off" for all fields (especially for type="text") is a huge mistake, don't say I didn't warn anyone! -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
That sounds like crbug.com/354257 which was fixed in March. Are you sure this is still a problem on newer versions of Chrome? On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar wrote: > Are you going to properly fire change&input events when autofill happens? > > The current autofill behavior is causing major headaches for application > and framework developers and by ignoring autocomplete attribute you disable > the only way developers can work around this bug. > > On angular we had to developer a special hack in an attempt to fix it, but > it's far from ideal: > https://github.com/angular/angular.js/issues/1460#issuecomment-33837127 > > The browser should let DOM know when autofill happens, so apps can treat > user input and autofill as the same. Right now this is not the case and it > sounds like you are going to make it only worse. > > \i > > > > On Thu Nov 13 2014 at 11:20:28 AM Evan Stade wrote: > >> Hi, >> >> Chrome already ignores the prevalent autocomplete="off" for password >> fields. We plan to ignore this tag for Autofill (addresses, credit cards) >> fields as well. autocomplete="off" will still be respected for >> autocomplete >> data (e.g. past searches on crbug.com). >> >> We think this will break a very small number of sites that use >> autocomplete="off" for legitimate reasons, e.g. they use the Google Maps >> Places Autocomplete API, and don't want Chrome trying to autofill in >> addition. But it will improve behavior for a much larger set of sites >> which >> use autocomplete="off" for confused reasons as a part of, e.g., their >> checkout flow. We have found the prevalence of autocomplete="off" in top >> sites' checkout forms to be quite high. >> >> Currently this new behavior is available behind a flag. We will soon be >> inverting the flag, so you have to opt into respecting autocomplete="off". >> >> I am curious what other browsers do around autocomplete="off", and if they >> respect it for address/user profile/credit card type data. Since there's >> no >> way to feature detect the browser's behavior, it would be convenient if >> all >> browsers agreed on the meaning/value of the attribute. >> >> -- Evan Stade >> >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen wrote: > On 2014-11-13 20:20, Evan Stade wrote: > >> Currently this new behavior is available behind a flag. We will soon be >> inverting the flag, so you have to opt into respecting autocomplete="off". >> >> > I don't like that browsers ignore HTML functionality hints like that. > > I have one real live use case that would be affected by this. > http://player.gridstream.org/request/ > This radio song request uses autocomplete="off" for the music request > because a listener would probably not request the same bunch of songs over > and over. > autocomplete="off" will still be respected for autocomplete data. This should cover your use case. > Also the reason the name field also has autocomplete="off" is simple, if > somebody uses a public terminal then not having the name remembered is nice. > Only the user can figure out if they're at a public terminal. > > Also, banks generally prefer to have autocomplete="off" for credit card > numbers, names, addresses etc. for security reasons. And that is now to be > ignored? > I'm not sure what security threat is addressed by respecting autocomplete="off". > > > Also note that in Norway this month a lot of banks are rolling out BankID > 2.0 which does not use Java, instead they use HTML5 tech. > And even todays solution (like in my bank) login is initiated by entering > my social ID number, which is entered into a input field with the text with > autocompelete="off". > Now my computer I have full control over but others may not (work place > computer, they walk off for a coffee) and someone could walk by and type > the first digit 0-9 and see whatever social id numbers had been entered. > This is also autocomplete, not Autofill (in Chrome parlance).
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 06:12, Peter Kasting wrote: On Thu, Nov 13, 2014 at 9:03 PM, Roger Hågensen wrote: This is getting more off topic but... have you ever typed wrong and now the autocomplete keeps listing your wrong spelling every time? And the only way to fix it is to nuke all your data, there is no way to edit/control the auto suggest data in a browser. I believe most browsers support shift-deleting entries from the autofill dropdown. PK Well, I'll be. Halfway there then. Only thing missing is a way to toggle autocomplete on and off. (or is that a hidden feature I've missed too?) Thanks BTW! -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 9:03 PM, Roger Hågensen wrote: > This is getting more off topic but... have you ever typed wrong and now > the autocomplete keeps listing your wrong spelling every time? And the only > way to fix it is to nuke all your data, there is no way to edit/control the > auto suggest data in a browser. I believe most browsers support shift-deleting entries from the autofill dropdown. PK
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 04:30, Glenn Maynard wrote: (Trimming for time and to avoid exploding the thread. Others can respond to the rest if they like.) No it's inherently correct for the use case as listeners tend to enter things like: "Could you play Gun's'Rose?" "Love you show, more rock please?" "Where are you guys sending from?" (You said "would probably not request the same bunch of songs over and over", and now you're replying as if you said something completely different.) What do you mean? "Where are you guys sending from?" vs "WSP please." vs "WASP please." If the listener presses "W" all those are suggested. I'm not sure if you have ever seen how listeners type but but there is a lot of weird things and miss-spellings. This is getting more off topic but... have you ever typed wrong and now the autocomplete keeps listing your wrong spelling every time? And the only way to fix it is to nuke all your data, there is no way to edit/control the auto suggest data in a browser. autocomplete they can just use textarea. Are you going to enforce autocomplete="on" for textarea now? I'm not worried about that at all. When autocomplete doesn't happen, people blame the browser (most people aren't web authors and don't know this is the web page's fault). When text entry is glitchy because the page used a textarea or other ugly hacks, it's the web page that looks bad. That's its own deterrant. And what about Webchat clients? What should for example a Websocket based chat client use for it's text input then? input type="text" autocomplete="off" makes sense in that case, using a text area does not make sense, you have to catch the pressing of the enter key for example as textarea can not trigger a onsubmit event. At the very least allow autocomplete="off" to still work on type="text" or simply make a new type="chat" where it can be set to off. "When autocomplete doesn't happen, people blame the browser" Yes and so do I when I have to dig into the bowls to force the darn thing off, I prefer to have autocomplete off for password fields as it helps train my memory into remember the myriad of passwords I use around the net. And now it's gonna autosuggest my passwords by default? Over the years I've been more annoyed with autocomplete being on than off, so I'm totally in reverse to how you are annoyed, but I'm not advocating getting rid of it because of that. It's annoying enough with websites informing me the website is using cookies, again and again and again. Same thing with "Would you like to remember this password?" and I click never. And then the next time I'm asked again, and again. If autocomplete="off" is going to be ignored and it'll always be on form now on then remove it from the specs fully, but at the very least create another spec that ensures a user can choose which sites and fields should and should not have autocomplete, leave it in the hands of the users, I'd be happy with that. Also the autocomplete list grows pretty big eventually, how do you clear it then? Some stuff like my email I might want to have autocomplete for but not other inputs (like a "Subject" field in a contact form), but to clear that I'll have to clear all the autocomplete stuff. If you can address my concerns or point out where how I can handle all this stuff then I'll be satisfied. But if the browser do not let me control my autocomplete then at least I'd want the web form to be able to do so, at least there the web developer might just have provided the option to toggle it unlike the browser. Take Chrome 38, i settings. Hidden behind "Show advanced settings..." under "Privacy" I'll find a button "Clear browsing data...". Clicking that I see a window and in it is a checkbox with "Autofill form data" as it's label. I have the option of clearing all form, autocomplete data or not at all. I'd rather have it a toggleable in the input field context menu and while at it a clear suggestions option for that field. Add that and I'll happily see autocomplete="off" and autocomplete="on" vanish from the spec, but not before. There is no granularity in the browser settings for autocomplete/fill/suggest. With autocomplete="off" and "on" there is at least some granularity (but obviously flawed otherwise this would be a non-issue). Also would a compromise be possible temporarily at least? Like autocomplete="off" working only for input type="text" ? -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
Are you going to properly fire change&input events when autofill happens? The current autofill behavior is causing major headaches for application and framework developers and by ignoring autocomplete attribute you disable the only way developers can work around this bug. On angular we had to developer a special hack in an attempt to fix it, but it's far from ideal: https://github.com/angular/angular.js/issues/1460#issuecomment-33837127 The browser should let DOM know when autofill happens, so apps can treat user input and autofill as the same. Right now this is not the case and it sounds like you are going to make it only worse. \i On Thu Nov 13 2014 at 11:20:28 AM Evan Stade wrote: > Hi, > > Chrome already ignores the prevalent autocomplete="off" for password > fields. We plan to ignore this tag for Autofill (addresses, credit cards) > fields as well. autocomplete="off" will still be respected for autocomplete > data (e.g. past searches on crbug.com). > > We think this will break a very small number of sites that use > autocomplete="off" for legitimate reasons, e.g. they use the Google Maps > Places Autocomplete API, and don't want Chrome trying to autofill in > addition. But it will improve behavior for a much larger set of sites which > use autocomplete="off" for confused reasons as a part of, e.g., their > checkout flow. We have found the prevalence of autocomplete="off" in top > sites' checkout forms to be quite high. > > Currently this new behavior is available behind a flag. We will soon be > inverting the flag, so you have to opt into respecting autocomplete="off". > > I am curious what other browsers do around autocomplete="off", and if they > respect it for address/user profile/credit card type data. Since there's no > way to feature detect the browser's behavior, it would be convenient if all > browsers agreed on the meaning/value of the attribute. > > -- Evan Stade >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
(Trimming for time and to avoid exploding the thread. Others can respond to the rest if they like.) On Thu, Nov 13, 2014 at 8:26 PM, Roger Hågensen wrote: > Punishing those who do it right because of the stupidity of the many, > can't say I'm too thrilled about that. Leaving it in is punishing every user of the Web. This is just one of many well-intentioned features that is failing in practice. > No it's inherently correct for the use case as listeners tend to enter > things like: > > "Could you play Gun's'Rose?" > "Love you show, more rock please?" > "Where are you guys sending from?" (You said "would probably not request the same bunch of songs over and over", and now you're replying as if you said something completely different.) > Is that what you want them to start doing? > If a bank or "security" site wishes to have input fields without > autocomplete they can just use textarea. > Are you going to enforce autocomplete="on" for textarea now? > I'm not worried about that at all. When autocomplete doesn't happen, people blame the browser (most people aren't web authors and don't know this is the web page's fault). When text entry is glitchy because the page used a textarea or other ugly hacks, it's the web page that looks bad. That's its own deterrant. On Thu, Nov 13, 2014 at 8:57 PM, Ben Maurer wrote: > If the site sets autocomplete=off could you disable the saving of new > suggestions? One of the main use cases for turning off autocomplete is to > disable the saving of sensitive or irrelevant information. If the user is > filling in an address or cc num it's likely they have the opportunity to > save that on other sites. > It wouldn't make sense for all sites to autocomplete credit cards, but only 50% to save them. -- Glenn Maynard
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 03:57, Ben Maurer wrote: If the site sets autocomplete=off could you disable the saving of new suggestions? One of the main use cases for turning off autocomplete is to disable the saving of sensitive or irrelevant information. If the user is filling in an address or cc num it's likely they have the opportunity to save that on other sites. Looking at https://wiki.whatwg.org/wiki/Autocompletetype I see credit cards has it's own subtype, this would allow some granularity (possibly tied to the security/privacy preferences of the user set in the browser). Then there is this http://blog.alexmaccaw.com/requestautocomplete (hmm, that name/email in the example image there looks very familiar... :P ) Now that is a very good incentive to actually use autocomplete, it saves me from having to start typing into every fields to trigger the autocomplete popuplist. -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 02:49, Glenn Maynard wrote: Unfortunately, even if a couple pages have a legitimate use for a feature, when countless thousands of pages abuse it, the feature needs to go. The damage to people's day-to-day experience outweighs any benefits by orders of magnitude. Also, banks generally prefer to have autocomplete="off" for credit card numbers, names, addresses etc. for security reasons. And that is now to be ignored? Yes, absolutely. My bank's preference is irrelevant. It's my browser, not my bank's. This is *exactly* the sort of misuse of this feature which makes it need to be removed. By default ignoring autocomplete="off" (unless the user crawls into the browser settings, possibly under advanced settings somewhere?) then those who miss-use it today will continue to do so. Take the following example (tested only in Firefox and Chrome). http://jsfiddle.net/gejm3jn1/ Is that what you want them to start doing? If a bank or "security" site wishes to have input fields without autocomplete they can just use textarea. Are you going to enforce autocomplete="on" for textarea now? Why not improve the way autocomplete works so there is a incentive to use it the right way? (sorry I don't have any clever suggestions on that front). My only suggestion now is: Default to autocomplete="off" working just as today. Provide a setting under Privacy settings in the browser (global). There are also per site privacy settings possible so (site specific). Then add a contexts menu to all input field where autocomplete can be enabled/disabled. (Spellcheck already does this for example in most browsers). -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
If the site sets autocomplete=off could you disable the saving of new suggestions? One of the main use cases for turning off autocomplete is to disable the saving of sensitive or irrelevant information. If the user is filling in an address or cc num it's likely they have the opportunity to save that on other sites. Sent from my iPhone > On Nov 13, 2014, at 2:20 PM, Evan Stade wrote: > > Hi, > > Chrome already ignores the prevalent autocomplete="off" for password > fields. We plan to ignore this tag for Autofill (addresses, credit cards) > fields as well. autocomplete="off" will still be respected for autocomplete > data (e.g. past searches on crbug.com). > > We think this will break a very small number of sites that use > autocomplete="off" for legitimate reasons, e.g. they use the Google Maps > Places Autocomplete API, and don't want Chrome trying to autofill in > addition. But it will improve behavior for a much larger set of sites which > use autocomplete="off" for confused reasons as a part of, e.g., their > checkout flow. We have found the prevalence of autocomplete="off" in top > sites' checkout forms to be quite high. > > Currently this new behavior is available behind a flag. We will soon be > inverting the flag, so you have to opt into respecting autocomplete="off". > > I am curious what other browsers do around autocomplete="off", and if they > respect it for address/user profile/credit card type data. Since there's no > way to feature detect the browser's behavior, it would be convenient if all > browsers agreed on the meaning/value of the attribute. > > -- Evan Stade
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-14 02:49, Glenn Maynard wrote: On Thu, Nov 13, 2014 at 7:17 PM, Roger Hågensen wrote: I have one real live use case that would be affected by this. http://player.gridstream.org/request/ Unfortunately, even if a couple pages have a legitimate use for a feature, when countless thousands of pages abuse it, the feature needs to go. The damage to people's day-to-day experience outweighs any benefits by orders of magnitude. Punishing those who do it right because of the stupidity of the many, can't say I'm too thrilled about that. This radio song request uses autocomplete="off" for the music request because a listener would probably not request the same bunch of songs over and over. (The use case doesn't really matter to me--the abuse is too widespread--but this is wrong. If I request a song today, requesting it again tomorrow or the next day is perfectly natural, especially if my request was never played.) No it's inherently correct for the use case as listeners tend to enter things like: "Could you play Gun's'Rose?" "Love you show, more rock please?" "Where are you guys sending from?" Also, banks generally prefer to have autocomplete="off" for credit card numbers, names, addresses etc. for security reasons. And that is now to be ignored? Yes, absolutely. My bank's preference is irrelevant. It's my browser, not my bank's. This is *exactly* the sort of misuse of this feature which makes it need to be removed. Then provide a way for the user (aka me and you) to toggle autocomplete for individual fields then. That way I could toggle autocomplete off for the request field. You wouldn't take away somebody's wheelchair without at least providing them a chair would you? (yeah stupid metaphor, I know, it sounded better in my head, really.) Also the reason the name field also has autocomplete="off" is simple, if somebody uses a public terminal then not having the name remembered is nice. This is another perfect example of the confused misuse of this feature. You don't disable autocompletion because some people are on public terminals--by that logic, every form everywhere would always disable autocomplete. This must be addressed on the terminal itself, in a consistent way, not by every site individually. (Public terminals need to wipe the entire profile when a user leaves, since you also need cache, browser history, cookies, etc.) Point taken. What about https://wiki.whatwg.org/wiki/Autocompletetype Couldn't a type="chat" be added then? That live example above was just one. What about web chat clients that use input type text? Do you really want autocomplete forced on always for that? If a user can't toggle autocomplete on/off per field as they want themselves then a type must exist where autocomplete is off by default. Is that too much to ask for? (as both a user and developer) -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 7:17 PM, Roger Hågensen wrote: > On 2014-11-13 20:20, Evan Stade wrote: > >> Currently this new behavior is available behind a flag. We will soon be >> inverting the flag, so you have to opt into respecting autocomplete="off". >> >> > I don't like that browsers ignore HTML functionality hints like that. > It's not ignoring hints, this is just removing a bad feature. One of the most common irritants of day to day browsing is pages disabling form autocomplete and password management, and making me enter everything by hand. It's working extremely poorly in the real world. I have one real live use case that would be affected by this. > http://player.gridstream.org/request/ Unfortunately, even if a couple pages have a legitimate use for a feature, when countless thousands of pages abuse it, the feature needs to go. The damage to people's day-to-day experience outweighs any benefits by orders of magnitude. > This radio song request uses autocomplete="off" for the music request > because a listener would probably not request the same bunch of songs over > and over. (The use case doesn't really matter to me--the abuse is too widespread--but this is wrong. If I request a song today, requesting it again tomorrow or the next day is perfectly natural, especially if my request was never played.) > Also, banks generally prefer to have autocomplete="off" for credit card > numbers, names, addresses etc. for security reasons. And that is now to be > ignored? Yes, absolutely. My bank's preference is irrelevant. It's my browser, not my bank's. This is *exactly* the sort of misuse of this feature which makes it need to be removed. > Also the reason the name field also has autocomplete="off" is simple, if > somebody uses a public terminal then not having the name remembered is nice. > This is another perfect example of the confused misuse of this feature. You don't disable autocompletion because some people are on public terminals--by that logic, every form everywhere would always disable autocomplete. This must be addressed on the terminal itself, in a consistent way, not by every site individually. (Public terminals need to wipe the entire profile when a user leaves, since you also need cache, browser history, cookies, etc.) -- Glenn Maynard
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On 2014-11-13 20:20, Evan Stade wrote: Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I don't like that browsers ignore HTML functionality hints like that. I have one real live use case that would be affected by this. http://player.gridstream.org/request/ This radio song request uses autocomplete="off" for the music request because a listener would probably not request the same bunch of songs over and over. Some might say that a request form should use a different input type like... well what? It's not a search input is it? There is no type="request" is it? in fact the request field is a generic text field that allows a short message if needed. PS! Please be aware that the form is an actual live form, so if you do enter and submit something be aware that there might be a live DJ at that point actually seeing your request. Why not treat autocomplete="off" as a default hint so if it's off then its off and if it's on then it's on but allow a user to right-click (to bring up the context menu for the input field) and toggle autocomplete for that field. I checked with Chrome, IE, Opera, Firefox, the context menu does not show a choice to toggle/change the autocomplete behavior at all (for type="text"). Also the reason the name field also has autocomplete="off" is simple, if somebody uses a public terminal then not having the name remembered is nice. Instead HTML5's sessionStorage is used to remember the name. Perhaps that could be a solution, that if autocomplete="off" is to be ignored by default then at least let the text cache be per session (and only permanently remember text if autocomplete="on" ?). Also do note that the type of field in this case is type="text". Also, banks generally prefer to have autocomplete="off" for credit card numbers, names, addresses etc. for security reasons. And that is now to be ignored? Also note that in Norway this month a lot of banks are rolling out BankID 2.0 which does not use Java, instead they use HTML5 tech. And even todays solution (like in my bank) login is initiated by entering my social ID number, which is entered into a input field with the text with autocompelete="off". Now my computer I have full control over but others may not (work place computer, they walk off for a coffee) and someone could walk by and type the first digit 0-9 and see whatever social id numbers had been entered. (or did I missread what you meant with autofill here?) -- Roger "Rescator" Hågensen. Freelancer - http://www.EmSai.net/
[whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
Hi, Chrome already ignores the prevalent autocomplete="off" for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete="off" will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete="off" for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete="off" for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete="off" in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I am curious what other browsers do around autocomplete="off", and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade
