我遇到了chrome自动填充行为的几个形式的问题。
表单中的字段都有非常常见和准确的名称，例如“email”、“name”或“password”，并且它们还设置了autocomplete=“off”。
自动完成标志已经成功禁用了自动完成行为，当你开始输入时，会出现一个下拉的值，但没有改变Chrome自动填充字段的值。
这种行为是可以的，除了chrome填充输入不正确，例如填充电话输入与电子邮件地址。客户抱怨过这个问题，所以它被证实在很多情况下都发生了，而不是我在我的机器上本地操作的某种结果。
目前我能想到的唯一解决方案是动态生成自定义输入名称，然后在后端提取值，但这似乎是一种相当笨拙的解决这个问题的方法。是否有任何标签或怪癖，改变自动填充行为，可以用来解决这个问题?
当前回答
我最终通过在输入字段中放入一个不重复的变量来解决这个问题-我使用php time()像这样:
<input type="text" name="town['.time().']" >
这主要是对机器人的干扰。我在服务器端所做的就是在输入名称上做一个foreach循环-问题是如果chrome识别名称属性，它将自动填充。
其他的都对我没用。
其他回答
如果表单是通过javascript生成的，那么通过在输入中添加“display: none;”来隐藏它的方法对我来说就行不通了。
所以我把它们放在视线之外，让它们隐形:
<input style="width:0;height:0;opacity:0;position:absolute;left:-10000px;overflow:hidden;" type="text" name="fakeusernameremembered"/>
<input style="width:0;height:0;opacity:0;position:absolute;left:-10000px;overflow:hidden;" type="password" name="fakepasswordremembered"/>
2022年4月:autocomplete="off"仍然不能在Chrome中工作，我不相信在查看了与此问题相关的Chromium bug后(可能只针对密码字段)。我看到2014年报告的问题被关闭为“WontFix”，问题仍然悬而未决，正在讨论[1][2]。据我所知，Chromium团队不相信有一个有效的用例autocomplete="off"。
总的来说，我仍然认为这两种极端策略(“总是尊重自动完成=关闭”和“从不尊重自动完成=关闭”)都是不好的。
https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66
他们的印象是，网站不会正确使用它，并决定不应用它，提出以下建议:
In cases where you want to disable autofill, our suggestion is to utilize the autocomplete attribute to give semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it. As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
https://bugs.chromium.org/p/chromium/issues/detail?id=587466#c10
虽然这个“建议”目前对我来说是可行的，但它可能并不总是正确的，看起来团队正在进行实验，这意味着自动完成功能可能会在新版本中改变。
我们不得不求助于这个是愚蠢的，但唯一可靠的方法是尽可能地迷惑浏览器:
在不向浏览器泄露任何信息的情况下为输入命名，例如id="field1"而不是id="country"。 设置autocomplete="do-not-autofill"，基本上使用任何不会让浏览器识别为可自动填充字段的值。
2021年1月:autocomplete="off"现在按预期工作(在Chrome 88 macOS上测试)。
要做到这一点，请确保input标记位于Form标记中
2020年9月:autocomplete=" Chrome -off"禁用Chrome自动填充功能。
原答案，2015年:
对于新版本的Chrome浏览器，你只需要在密码栏中输入autocomplete="new-password"就可以了。我检查过了，工作正常。
在这次讨论中，我从Chrome开发者那里得到了一个建议: https://bugs.chromium.org/p/chromium/issues/detail?id=370363#c7
P.S. Note that Chrome will attempt to infer autofill behavior from name, id and any text content it can get surrounding the field including labels and arbitrary text nodes. If there is a autocomplete token like street-address in context, Chrome will autofill that as such. The heuristic can be quite confusing as it sometimes only trigger if there are additional fields in the form, or not if there are too few fields in the form. Also note that autocomplete="no" will appear to work but autocomplete="off" will not for historical reasons. autocomplete="no" is you telling the browser that this field should be auto completed as a field called "no". If you generate unique random autocomplete names you disable auto complete.
如果你的用户访问了不好的表单，他们的自动填充信息可能会被损坏。让他们手动进入并修复Chrome中的自动填充信息可能是他们采取的必要行动。
这里有两个部分。Chrome和其他浏览器会记住之前输入的字段名的值，并基于此为用户提供一个自动完成列表(值得注意的是，密码类型的输入永远不会以这种方式记住，原因相当明显)。你可以添加autocomplete="off"来防止这种情况发生在你的电子邮件字段上。
但是，您还可以使用密码填充器。大多数浏览器都有自己的内置实现，也有许多第三方实用程序提供此功能。这个，你停不下来。这是用户自己选择保存该信息以便稍后自动填写，完全超出了应用程序的范围和影响范围。
而不是“这对我来说是有效的”的答案和其他看起来完全像黑客的答案……这是目前chrome(和最新的规范)将如何处理输入元素上的自动完成属性:
https://developers.google.com/web/fundamentals/design-and-ui/input/forms/label-and-name-inputs?hl=en
TLDR:在您的输入上添加autocomplete='<value>'，其中<value>应该是定义字段用途的任何字符串。这类似于name属性。尽可能使用上面链接上的建议值。
另外，从表单中删除autocomplete属性
所以显然，最好的修复/黑客现在不再工作，再次。我使用的Chrome版本是49.0.2623.110 m和我的帐户创建形式现在显示保存的用户名和密码与形式无关。由于铬!其他黑客似乎很可怕，但这个黑客不那么可怕……
为什么我们需要这些黑客工作是因为这些形式通常是帐户创建形式，即不是登录形式，应该允许填写密码。帐户创建表单您不希望删除用户名和密码的麻烦。从逻辑上讲，这意味着在呈现时永远不会填充密码字段。所以我使用了一个文本框，加上一点javascript。
<input type="text" id="password" name="password" />
<script>
setTimeout(function() {
$("#password").prop("type", "password");
}, 100);
// time out required to make sure it is not set as a password field before Google fills it in. You may need to adjust this timeout depending on your page load times.
</script>
我认为这是可以接受的，因为用户不会在短时间内获得密码字段，并且如果该字段是密码字段，则发送回服务器没有任何区别，因为无论如何它都是以纯文本发送回来的。
Caveat: If, like me, you use the same creation form as an update form things might get tricky. I use mvc.asp c# and when I use @Html.PasswordFor() the password is not added to the input box. This is a good thing. I have coded around this. But using @Html.TextBoxFor() and the password will be added to the input box, and then hidden as a password. However as my passwords are hashed up, the password in the input box is the hashed up password and should never be posted back to the server - accidentally saving a hashed up hashed password would be a pain for someone trying to log in. Basically... remember to set the password to an empty string before the input box is rendered if using this method.
