Hacker News Reader

Comment by heinrichhartman | Hacker News Reader

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.

View on HN

The problem is when the web browser gets it wrong and decides to show autocomplete for an unrelated field, or a field that is not a login/enter password page. Some examples I've had to deal with:

1. A "name" field on a dialog for creating values in a controlled vocabulary (e.g. genres in fiction) -- Chrome thinks this is a username field so brings up a user autocomplete. I guess it thinks that "Jane Smith" is a valid label!

2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password.

With these, I've had to employ several workarounds to tell the web browsers that these are not login forms, so please don't autocomplete them as such, all because they ignore `autocomplete="off"`. I've got these working now, but if Chrome/Firefox decide to ignore the markup because of sites misusing them (like they've done before), I'll need to work out how to avoid this again.

I write web apps for a living and literally ran into this last week...and was promptly annoyed when I realized chrome was ignoring the attribute to disable it.

I understand the pain, and the need to somehow work around this.

However, conceptually the right place to fix/configure this is the browser. So the correct long-term approach is to open a bug/feature request and get this properly addressed. Everything else is, well, -- a workaround.

(Again: I understand that the correct approach can take years, and it is unclear if it will succeed at all - so it may be impractical.)

Another great example is github - for awhile, trying to request a review from someone on a pull request would cause LastPass to "helpfully" pop up and prompt for an auto-fill, completely obscuring the list of users underneath.

> 2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password.

Even if you add `autocomplete="email"` to that field?

It's been a while since I had that issue, so can't remember the exact details of what I tried at the time, and the workaround for that hasn't broken recently.

No, the website should have the option to overwrite the browser decision.

For example, for a multiplayer game I worked on, you could set a password when you create a private room in the game. The browser always auto-filled it with your account password, which is definitely not good because you have to share the room password with others. Telling the browser to not autocomplete that filled didn't work, because "the browser should know better than the website" thing you mentioned.

For this specific case, the website could generate a password on room creation and show it to the user in a non-editable field.

Users want to choose the password themselves because they have to share it with others, so they usually create a funny password.

>IMHO, the decision of whether to show auto-complete should be with the user and not with the website.

There's a setting in Chrome where you can disable auto-complete on a field-by-field basis?

As far as I know there is not, but I wish there was! Or even on a website-by-website basis. On the UPS website there's a screen where I can't use autofill to enter an email address for shipping notifications without it also overwriting the shipping address fields to whatever address I have stored for that email address.

I think that what this ignores is that if anybody has clout over behavior, it's Google. They don't have to break their own Angular Material autocomplete or burden devs with unpredictable behavior like this.

Well the alternatives may not be perfect, this clearly isn't either. They can create videos rebuking disabling password fields, or put warnings in the webmaster console, or apparently just release a vague statement about how "disabling password fields or disabling pasting in to them will now majorly detract your placement in search results" and turn the Marketing/SEO team against bad security contractors.

> IMHO, the decision of whether to show auto-complete should be with the user and not with the website

It;s fundamentally wrong to decide what 'rights' website users have (aside from when it comes to privacy).

There are myriad ways how a website can become un-user friendly to the point of being unusable not the least is of which you can completely disable the cursor or completely not display certain parts which are really there (e.g. display: none).

Point being there is a fundamental 'trust' which a user gives to a website developer, that the website they visit will behave as 'the developer' intended. The user even expects to get the site just s the developer created it, however 'bad' that may be.

Now of course it is in the interest of the web developer to make their site user-friendly if they want to appeal to a wide populace. But it is totally in the purview of the developer to make the site even completely unusable.

I don't understand how a browser has the audacity to force their assumptions on site behavior on the user/developer.

It's especially bad because the holier-than-thou attitude broke real, commonly-used websites , the Chrome team was made aware of the use cases, and they just didn't care. For example, Chrome tried auto-completing my home address into Expedia for where I'd like to vacation.

So it's not even those "corner case big boring CRM business apps" that had to find workarounds to forced-autocomplete, it's "real" user-facing ones too. Very frustrating.

Reply on news.ycombinator.com