Comment by crabmusket
1 day ago
> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints
Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this.
The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour.
https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41239842
(By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.)
The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.
Problem with autocomplete=off is some morons think they should use it on their login form for "security" or whatever, cause forcing users to type in passwords is "secure". So browsers wound up having to ignore it for actual security.
Browsers could have instead allowed me to right click and say "insert password because I know what I'm doing". But browsers are in the business of training users to be stupid, rather than acting as a user's loyal agent, so I guess we were mercifully spared this future.
This creates band-aid after band-aid. Like every user-agent is mozilla now.
Repeat after me: never fuck with spec implementation. If you don't like writing to a spec, write other types of software.
Let the ecosystem (website owners) face consequences of their own actions. It is better to blacklist bad actors then filling your software with bugs.
I am one of those morons who had to build a page for someone to go to the nurse's office and input all their information without it being saved for the next person who goes there to fill their information.
Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
> Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
Well, too bad, because that's exactly what the solution should be.
Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`.
> We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers.
"We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
> Usually it amounts to being more descriptive in the value of the `autocomplete` attribute
No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete.
In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway.
> but not filed a bug?
It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
Chrome's slogan: "L'internet, C'est moi."
[flagged]
3 replies →
Believe it or not, I have observed autocomplete behavior for an input change based on its label text.