Earlier quoted context omitted.
Are there any viable cases?
OTP one-time-password fields
autocomplete="one-time-code"
Any others?
Safari tries to fill username
51–60 of 393 posts
Re: Safari tries to fill username
#52Why would someone even use Safari instead of Chrome? Hell I would rather use Edge.
I occasionally use Safari to extend battery usage on a laptop. For me Chrome uses significantly more power.
Re: Safari tries to fill username
#53Earlier quoted context omitted.
It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.
Why? The spec ain't God given.
> Or they should go and push for spec change
Re: Safari tries to fill username
#54Why would someone even use Safari instead of Chrome? Hell I would rather use Edge.
Chrome tears through RAM and battery
Re: Safari tries to fill username
#55Does it work in other languages ?
Just tested it in Dutch ("Welkom terug"), which does not trigger the autocomplete.
Re: Safari tries to fill username
#56Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466
I tend to side with Chrome here.
IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not.
Now, there is a valid question on how the user should be able to configure the AC behavior, and how the website may help inform this configuration, but the decision should be with the user. The website should not have the final say.
So I would see this as more of a shortcoming of the HTML Spec.
Re: Safari tries to fill username
#57Earlier quoted context omitted.
Yes. The Chrome devs refuse to accept there are viable cases for not allowing autocomplete.
It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.
The spec is driven by browser implementations rather than the other way around, is it not?
Re: Safari tries to fill username
#58Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466
The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years, and so tons of websites followed that advice and dutifully disabled the functionality. But autocomplete has advantages: it lets users easily specify long, random, per-site passwords without ever having to worry about that. And when they can't do that, a pretty large percentage of them just give up and write the passwor…
I'd go a step further and say if my password manager doesn't play nice with a website, I'm less likely to use that website.
Re: Safari tries to fill username
#59Earlier quoted context omitted.
OTP one-time-password fields
autocomplete="one-time-code" Any others?
good point!
But as soon as browsers stop autocompleting fields marked with autocomplete="one-time-code", won't website developers start marking _all_ input fields with this tag? After all, why do people put autocomplete="off" on input fields anyway?
Re: Safari tries to fill username
#60It _wants_ to autofill, but it doesn't without the user actually confirming the autofill. Pretty important distinction to make I think