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.

> It's clear the Chrome team has no interest in fixing this behaviour

It's clear to me that you only vaguely remember a bug that no one can repro. Nobody has time for that.

If you're a Chromium contributor or otherwise involved, I'd be happy to chat further about this and work up a submission to demonstrate the issue with a minimal repro. But if not, I don't think they need you to stick up for them.

It's clear from the threads I did post that lots of devs are frustrated with Chrome's behaviour and the team's lack of attention to not just fixing bad behaviour, but complying with the HTML spec. Without even focusing on the type=number problem, I have spent enough time fighting other behaviour which is only an issue in Chrome.

> you only vaguely remember a bug

Thanks to that ad-hom I am now irritated, and I went back to our internal Slack to find the screenshot of the type=number bug. Sharing a screenshot here would have no real value to this discussion, but it's real.

A cursory search would show you how much frustration there is around broken autofill attributes. Such a dismissive attitude helps no one. Would you like me to paste the contents of the Jira issue I did last month working around a password input where we couldn't turn off autofill?

Chrome's slogan: "L'internet, C'est moi."

Believe it or not, I have observed autocomplete behavior for an input change based on its label text.

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.

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.

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.