Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome does not respect autocomplete=off (2018)

bugs.chromium.org

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Chrome does not respect autocomplete=off (2018)

#71

Post by rsj_hn »

hombre_fatal wrote: post #51

Unfortunately, the decision to ignore the autocomplete attribute also makes it very hard to help the browser pick up the appropriate autofill username/password fields. All browsers right now basically assume that if you have an input type="password", then the previous input type="text" must be the username field. And there's little you can do to change this without resorting to substantial hacks like using a hidden u…

That's interesting. I almost never see "please enter password to confirm" but I always see (the more annoying) please enter username and password to confirm. Now I know why.

Re: Chrome does not respect autocomplete=off (2018)

#73

Post by globular-toast »

I have mixed feelings. I get the user agent argument, although it's hilarious to hear people say this about Chrome. My biggest pet peeve is that websites can decide to not let me use "/" to search in the page. They "cleverly" move your cursor to the search box. I have to use the clunky ctrl-f instead.

But I've also been bitten by autocomplete bugs. It has a strong tendency to make the user do the wrong thing and then forces developers to use silly hacks to stop it. It's not as bad as the IE6 days, but it's not ammillion miles away.

Re: Chrome does not respect autocomplete=off (2018)

#74

Post by traspler »

I was a bit shocked when I was hit by this a couple of years back (2017) and learned that browsers are adamant about providing autocomplete, going so far as to infer the type from labels or placeholder strings.

The problem was even more frustrating because it seemed like disabling it was the only workaround to prevent a strange mobile Safari issue where the autocomplete bar would push the "next/prev element - Done" bar, on top of the keyboard, up so it would overlap the "position: fixed; bottom: 0;" element on the page (which was the input the user was trying to write into).

The argument that the user would complain to the browser vendor if he couldn't autocomplete is a bit strange to me. I would think the real novice users would begrudgingly accept the inconsistent behaviour and the users that do care about it would complain to the website they were on. But then again I haven't read any user studies regarding this.

Re: Chrome does not respect autocomplete=off (2018)

#75

Post by Traubenfuchs »

ncann wrote: post #48
dataflow wrote: post #42

Why don't they put a flag to control this behavior in the browser? So that users who want it to be respected can actually get that?

Chrome is extremely anti user choice. They have a very "we know better than you" attitude. There is about:flags but most flags are temporary and are eventually removed.

Every flag worsens complexity, size and maintainability...

Re: Chrome does not respect autocomplete=off (2018)

#77

Post by wbercx »

Spivak wrote: post #16
nikanj wrote: post #2

It’s pretty incredible to see the amount of steaming developers commenting on this issue. What tools do developers have, when platform providers turn a deaf ear to their needs?

The problem is that you’re only seeing angry developers and not the angry users frustrated that they can’t use autofill on sites that disable it for no real reason. Sites being able to change the behavior of the user-agent is almost always a bad thing. autocomplete=off should just be removed and it be entirely up to the user-agent whether it gets used like reader mode.

I've had several of our users call up over the years, angrily asking why we made certain fields in our app "dropdowns" with rubbish in them.

Chrome decided to add autocomplete to some of our fields with contextually irrelevant options. As far as I know there isn't anything I can reliably do about it.

Re: Chrome does not respect autocomplete=off (2018)

#78

Post by harg »

mad182 wrote: post #76

As a user, I think Chrome ignoring autocomplete=off is great and if it was a flag, I would enable it without hesitation. This feature is misused all the time.

How do you feel about the examples given in the thread like autocomplete suggestions overlaying a datepicker? Surely that's not great for anyone.

It may well be that disabling autocomplete is open to abuse, but it's not up to the browser venders to police the quality of webpages. There are plenty of other features that are abused all the time. Should browsers disable window.onscroll because it can be misused? How about all of JavaScript?

Re: Chrome does not respect autocomplete=off (2018)

#79

Post by fmajid »

wbercx wrote: post #77
Spivak wrote: post #16

Earlier quoted context omitted.

The problem is that you’re only seeing angry developers and not the angry users frustrated that they can’t use autofill on sites that disable it for no real reason. Sites being able to change the behavior of the user-agent is almost always a bad thing. autocomplete=off should just be removed and it be entirely up to the user-agent whether it gets used like reader mode.

I've had several of our users call up over the years, angrily asking why we made certain fields in our app "dropdowns" with rubbish in them. Chrome decided to add autocomplete to some of our fields with contextually irrelevant options. As far as I know there isn't anything I can reliably do about it.

Make the form field names randomly generated each time the page is loaded, and decrypt them server-side.

Re: Chrome does not respect autocomplete=off (2018)

#80

Post by quink »

hombre_fatal wrote: post #51

Unfortunately, the decision to ignore the autocomplete attribute also makes it very hard to help the browser pick up the appropriate autofill username/password fields. All browsers right now basically assume that if you have an input type="password", then the previous input type="text" must be the username field. And there's little you can do to change this without resorting to substantial hacks like using a hidden u…

autocomplete="username"

autocomplete="current-password"

Post reply on HN