我遇到了chrome自动填充行为的几个形式的问题。

表单中的字段都有非常常见和准确的名称,例如“email”、“name”或“password”,并且它们还设置了autocomplete=“off”。

自动完成标志已经成功禁用了自动完成行为,当你开始输入时,会出现一个下拉的值,但没有改变Chrome自动填充字段的值。

这种行为是可以的,除了chrome填充输入不正确,例如填充电话输入与电子邮件地址。客户抱怨过这个问题,所以它被证实在很多情况下都发生了,而不是我在我的机器上本地操作的某种结果。

目前我能想到的唯一解决方案是动态生成自定义输入名称,然后在后端提取值,但这似乎是一种相当笨拙的解决这个问题的方法。是否有任何标签或怪癖,改变自动填充行为,可以用来解决这个问题?


当前回答

如果显示:none不工作,这也是可能的,它似乎是工作的(Chrome v60.0.3112.113):

.hidden-fields {
    opacity: 0;
    float: left;
    height: 0px;
    width: 0px;
}

<input type="text" name="username" class="hidden-fields"> 
<input type="password" name="password" class="hidden-fields">

<your actual login fields></your actual login fields>

其他回答

对于用户名密码组合,这是一个很容易解决的问题。Chrome启发式查找模式:

<input type="text">

紧随其后的是:

<input type="password">

简单地通过使其无效来中断这个过程:

<input type="text">
<input type="text" onfocus="this.type='password'">

在chrome浏览器中,如果你用标签包围一个输入,在标签内加上街道、地址或两者都写上,它会忽略任何试图禁用自动填充的尝试。

<label for="searchAddress" class="control-label"> Street Address <input type="text" class="form-control" name="searchAddress></label>

Chrome通过检测标签中的关键字来判断输入类型。它可能对其他关键字也是如此。

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实际上填充了许多字段。我还需要以一种比显示更花哨的方式隐藏字段:没有字段才能实际工作。

<style>.stylish { position:absolute; top:-2000px; }</style>
<input id="_____fake_email_remembered" class="stylish" tabindex="-1"  type="email" name="email_autofill"/> 
<input id="_____fake_userName_remembered" class="stylish" tabindex="-1"  type="text" name="userName_autofill"/>
<input id="_____fake_firstName_remembered" class="stylish" tabindex="-1"   type="text" name="firstName_autofill"/>
<input id="_____fake_lastName_remembered" class="stylish" tabindex="-1"   type="text" name="lastName_autofill"/>
<input id="_____fake_phone_remembered" class="stylish"  tabindex="-1"  type="text" name="phone_autofill"/>
<input id="_____fake_address_remembered" class="stylish"  tabindex="-1"   type="text" name="address_autofill"/>
<input id="_____fake_password_remembered" class="stylish"  tabindex="-1"   type="password" name="password_autofill"/>
<input id="_____fake_password_remembered2" class="stylish"  tabindex="-1"   type="password" name="passwordRepeated_autofill"/>

所以显然,最好的修复/黑客现在不再工作,再次。我使用的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.