Remix clone Hacker News

> 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.

▲

streptomycin a day ago | parent | next [-]

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.

▲

crabmusket a day ago | parent | next [-]

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.

▲

exceptione 21 hours ago | parent | prev | next [-]

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.

▲

mcny a day ago | parent | prev [-]

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.

	▲	pwdisswordfishz 21 hours ago \| parent [-]
		> 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.

▲

dfabulich a day ago | parent | prev [-]

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.

▲

crabmusket a day ago | parent | next [-]

> 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.

▲

exceptione 21 hours ago | parent | next [-]

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

▲

dfabulich a day ago | parent | prev [-]

[flagged]

	▲	crabmusket a day ago \| parent \| next [-]
		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.
	▲	schiem a day ago \| parent \| prev \| next [-]
		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?
	▲	a day ago \| parent \| prev [-]
		[deleted]

▲

prmph a day ago | parent | prev [-]

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