当前在 Safari 中运行 1Password 7.7 Beta-2，该版本现已具备类似 1PasswordX 的特定字段自动填充功能。目前，它会将任何可能包含用户名的字段视为 1Password 的自动填充字段。这反过来会覆盖 Discourse 的选项，导致“输入并搜索”功能失效。请参见下图：
我在 1Password 的网站上进行了一些调查，以了解如何在 HTML 中禁用此功能，并找到了以下内容：
4 个赞
我前段时间在 Chrome 上也遇到过这个烦人的问题，但最近情况有所好转。也许它已经停止出现，或者我已经习惯了。那时我会按 ESC 键来隐藏 1Password 的覆盖层，之后 Discourse 的选项就会显示出来。
我还记得自己好像在 1Password 的字段选项中点击了禁用，但我不太确定。目前我在手机上，所以无法完全确认。
4 个赞
我也觉得这相当烦人。在像“向群组添加成员”这样的模态窗口中，按 Esc 键效果不佳，它只会关闭窗口。唯一能消除它的方法是点击下拉菜单并选择“在此页面上隐藏”，但这仅对这一次有效。这是在 Firefox 中遇到的情况。
3 个赞
看起来 1Password 使用机器学习来确定激活位置，因此直到最近（上个月）还没有可靠的方法来禁用它。
相关的支持讨论 指出，他们最近开始检查 autocomplete=off……但我们已经在用 autocomplete=discourse，因为 Chrome 会忽略 autocomplete=off，并尝试用其保存的表单数据自动填充 
。
9 个赞
我们中有很多人是付费用户，我们应该向 1Password 施压。如果他们能在这里提供某种其他渠道、不同的属性……任何方式，我们都能有所作为。
我们的双手被谷歌的固执所束缚。
如果您是 1Password 用户，请：
-
在论坛主题中发帖，就像 @awesomerobot 所做的那样
-
联系 1Password 支持团队
我也会在周一提醒触发时这样做。
8 个赞
我的一天已经结束了！
论坛用户 ag_yaron 提供了很多帮助，您能否按照以下说明为 1Password 团队发布更多信息？
1 个赞
@sam 已经在 1Password 论坛上引起了大家对支持讨论的额外关注，他们希望我们就 Discourse 中有问题的字段提供反馈，以便他们知道该从哪里入手。我们可以分享我们注意到问题的具体位置吗？
就我个人而言，我倾向于说，一旦我解锁了 1Password X 浏览器扩展，几乎每个文本框或字段都会显示该问题，因为我在 Discourse 中尚未见过它不弹出的字段。但最让人恼火的是在 /admin/settings 页面通过设置过滤器进行搜索时：
它不应该在那里显示！@galligan @davidkingham @awesomerobot，还有其他具体的字段吗？我们在这里分享的内容，1Password 团队的 Jarek 将能够看到，或者我会直接分享给 Jarek，所以请畅所欲言！
3 个赞
是的，这在我们的许多输入中普遍存在，但我认为问题最严重的是当我们尝试显示建议结果时，因为它会覆盖我们的下拉菜单。
如果你在主题底部点击“分享”并尝试使用“发送邀请”选项卡…
1Password 完全覆盖了下拉菜单：
正常情况下应该显示为：
4 个赞
大家好！
我是 1Password 扩展团队的 Jarek。今天早上我花了一些时间查看了 @osioke 为我们搭建的 Discourse 试用实例（非常感谢！），以下是我的发现。
我查看了该特定字段，看起来在最新的 1Password X 稳定版本中，我们已不再显示。我在内部添加了一个测试用例，以确保我们今后永远不会再在此处显示！
我确认了我们确实在此处显示，并且已在内部添加了测试用例，并做出了一项更改以防止此类情况再次发生（基于字段上方的标签提到了“邀请”）。当下一版 1Password X 测试版发布时，请在此处尝试一下 
。
我在以下 URL 发现了一个字段，遗憾的是，我们在自己的端无法对此采取任何措施（admin/users/list/active 路由）：
我们用于收集页面信息的脚本为该字段收集了以下信息：
{
"htmlId": "ember921",
"htmlClass": "ember-text-field ember-view",
"isActive": true,
"opid": 5,
"placeholder": "username, email or IP address",
"type": "text",
"labelBefore": "Show Emails"
},
这里没有任何内容可以让我用来帮助 1Password 理解不应在此字段中显示。就 1Password 所知，这可能是一个需要自动填充的登录字段。
你们可以做一些事情来帮助 1Password。首先，可以使用 autocomplete="off" 属性。我们最近推出了一种新策略，用于尝试遵循该属性的意图。如果该字段设置为 autocomplete="off"，则字段下方的菜单选项将默认隐藏，用户体验将大幅改善。
我理解由于 Chrome 团队的一些决定，这做起来很困难；我们内部曾讨论过将类似 autocomplete="discourse" 的内容视为与 autocomplete="off" 相同，虽然目前我无法做出任何承诺，但可以表示这已在我们的考虑范围内。
不过，还有一件更好的事情你们可以做。为了让 1Password 完全忽略该字段，我们需要表明该字段是用于搜索而非登录。你可以通过给该字段添加 name="user-search" 属性（或 id="user-search"）来实现这一点。1Password 会看到名称或 ID 末尾的 search，从而避免为该字段建议登录信息。
应用该更改后，该字段将如下所示：
1Password 将不再为该字段提供任何建议。这是你现在就可以对任何此类搜索字段进行的更改，以防止 1Password 显示！
我还注意到在 admin/email 路由下有一个“测试邮箱地址”字段，该字段若能使用 autocomplete="off" 将会受益匪浅。
以上就是我注意到的问题。如果我遗漏了任何内容，请告诉我。很乐意继续在这里讨论！我们一直在努力改进建议功能，并更准确地判断何时显示或不显示。
12 个赞
这非常有帮助，谢谢！
我们确实期望用户在测试电子邮件配置时在该框中输入自己的电子邮件地址。
7 个赞
是的，我强烈建议采用这一策略，因为我认为 Chrome 不会改变。
感谢你们的辛勤付出！
8 个赞
最近有人在他们的 Discourse 网站上遇到过 1Password 的问题吗？我跟进一下以确认，因为已经过去一年了。
就我这边而言，这似乎更多是浏览器（Microsoft Edge）的问题，而非 Discourse 本身的问题，因此无需在此提及。
这仍然是一个持续存在的问题。我正在使用 Safari v15 和最新的 1Password 测试版，但问题依旧存在。
请注意，当我在用户管理页面的用户名字段中点击时，它会尝试激活 1Password。
4 个赞
感谢您分享这些，Matt！
您还发现 1Password 在其他哪些地方出现了？
这里的文本框是一个用户名字段，因此从技术上讲，1Password 应该在那里弹出。但不幸的是，作为管理员在编辑成员用户名时，这并非您的用户名字段，所以我理解这可能并不理想。
另外，这也已与 1Password 团队分享 
再次感谢你的分享，Matt！
2 个赞