141–150 of 383 posts
It's frustrating, we've used workarounds, which then stop working and reports come flooding in again. It's crazy to me that the Chrome team think this is better for users, and that there isn't a more intelligent workaround for sites abusing autocomplete=off.
Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks
Earlier quoted context omitted.
I think we need a way to disable features only for those developers that abuse them. Like uMatrix but built-in and with rules being supplied automatically as ad blocking lists are. You autocomplete=off a password field? That attribute won't have an effect on your site anymore. You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned. Scroll hijack…
Can we have a reliable cross-browser way to say "this is a change password field, so don't autocomplete it" and "this is an email address field not a username field, so don't autocomplete it with the login username"?
Earlier quoted context omitted.
You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.
Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
As I had already commented on the issue, it completely breaks Germany's main train ticket selling website: https://i.imgur.com/BjYTgSn.png They have tagged the field as autocomplete=off but Chrome just doesn't care. Also see this linked issue where they collected valid use cases for autocomplete=off. They just seem to ignore 452 use cases (I can't comment on the quality of them, I did not read any). https://bugs.chro…
Can anyone explain why the same behavior does not occur on https://www.sbb.ch/ , the Swiss equivalent (which is based on the same software by HaCon)? E: as soon as you submit a search on sbb.ch, the same problem occurs.
Earlier quoted context omitted.
I think we need a way to disable features only for those developers that abuse them. Like uMatrix but built-in and with rules being supplied automatically as ad blocking lists are. You autocomplete=off a password field? That attribute won't have an effect on your site anymore. You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned. Scroll hijack…
Can we have a reliable cross-browser way to say "this is a change password field, so don't autocomplete it" and "this is an email address field not a username field, so don't autocomplete it with the login username"?
It's really frustrating to have to work around this with hit or miss hidden inputs and such. So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text. Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
Earlier quoted context omitted.
Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
"the most "valuable" users are all on mobile Safari" Not at all, as only 20% of the people using mobile browsers at all, are using Safari.
Earlier quoted context omitted.
> somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
It's complicated. Sometimes website authors do silly things that negatively impact users; browsers ought to help (without breaking things!) where possible. Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijac…
Of course, all those features can also be abused, but that doesn't mean it's a good idea to try and second-guess website authors; that just makes things much much more complicated for everyone.
Any feature can be abused in any platform, and as the web has moved towards an "application platform" – instead of just a document viewing platform – there are many more features with potential for abuse, but it also becomes much more important that behaviour is consistent and predictable.
I'm most definitely not on the "the specification is holy"-side of things, but from what I read in this issue the Chrome team seems surprising tone-deaf to concerns about Chrome's behaviour here. This is general patterns I see with Chrome, which confuses "it works for the majority of cases/users" with "it works well". These are simply not the same things.