Currently running 1Password 7.7 Beta-2 in Safari, which now has the 1PasswordX-like auto-fill feature of certain fields. Right now it’s treating any field that might contain usernames as an autocomplete field for 1Password to fill. That in turns is overriding the Discourse options, rendering type-and-search useless. See image:
I did some digging on 1Password’s website to see how to potentially disable this in the HTML and found this:
https://support.1password.com/compatible-website-design/
I also found this annoying a while back on Chrome, but less so recently. Maybe it has stopped or I have gotten used to it. Back then I’d use the ESC key to hide 1Password’s overlay, and it allowed the Discourse options to show after.
I also think I clicked the disable on the field options in 1Password too, but I am not sure. Currently on Mobile so I can’t say for sure.
I’ve found this rather annoying too, Esc doesn’t work too well when it’s in a modal window like adding members to a group which just dismisses the window. The only way to get rid of it is by clicking the drop down and select hide on this page, which only works for that one time. This is in Firefox.
It looks like 1Password uses machine learning to determine where to activate, so until recently (last month) there was no surefire way to disable it.
The related support discussion says they recently started checking for autocomplete=off… but we’re already using autocomplete=discourse because Chrome ignores autocomplete=off and tries to autocomplete with their saved form data 
Lots of us are paying customers we should lobby 1password here, if they give us some sort of other outlet here, a different attribute… anything, we can do something
Our hand are tied by Google being stubborn
if you are a 1password user please
Post on the forum topic like @awesomerobot did
Contacts 1password support
I will do so on Monday as well when my reminder fires
My day has ran out!
ag_yaron on the forum has been very helpful, would you mind posting extra info for the 1password team using these instructions?
@sam has been able to get some extra attention on the support discussion on 1Password’s forum, and they’d like to get our feedback on the problematic fields in Discourse, so they know where to look. Can we share where we noticed the issue?
For me I am tempted to say it shows on almost every textbox or field once I have unlocked my 1Password X browser extension, because I haven’t seen a field it does not pop up on in Discourse, but it was most annoying when searching through the settings filter on /admin/settings:
It shouldn’t show there! Any other specific fields @galligan @davidkingham @awesomerobot? What we share here, Jarek from the 1Password team will be able to see or I’ll share with Jarek, so fill away!
Yeah it’s generally across a lot of our inputs, but I think the biggest offenders are when we’re trying to suggest results because it covers our dropdowns.
If you click share at the bottom of a topic and try to use the “send invite” tab…
1Password completely covers our dropdown:
Normally it should look like:
Salut à tous ! 
C’est Jarek de l’équipe des extensions 1Password. J’ai passé un peu de temps ce matin à explorer l’instance d’essai Discourse que @osioke a configurée pour nous (merci pour ça !), et voici ce que j’ai constaté.
J’ai examiné ce champ spécifique et il semble que nous n’apparaissions plus depuis la dernière version stable de 1Password X. J’ai ajouté un cas de test en interne pour nous assurer que cela ne se reproduise plus jamais ici ! 
J’ai confirmé que nous apparaissions ici, et j’ai ajouté un cas de test en interne et apporté une modification qui empêchera cela de se produire (en se basant sur le fait que l’étiquette au-dessus du champ mentionne « invitation »). Dès que la prochaine version bêta de 1Password X sera publiée, n’hésitez pas à l’essayer ici 
.
J’ai trouvé un champ à l’URL suivante sur lequel je ne peux malheureusement rien faire de notre côté (route admin/users/list/active) :
Notre script de collecte d’informations sur la page rassemble les informations suivantes pour ce champ :
{
"htmlId": "ember921",
"htmlClass": "ember-text-field ember-view",
"isActive": true,
"opid": 5,
"placeholder": "nom d'utilisateur, adresse e-mail ou adresse IP",
"type": "text",
"labelBefore": "Afficher les e-mails"
},
Il n’y a rien ici que je puisse cibler pour aider 1Password à comprendre qu’il ne doit pas apparaître dans ce champ. Pour tout ce qu’il sait, cela pourrait être un identifiant nécessitant une saisie automatique.
Il y a quelques choses que vous pouvez faire pour aider 1Password ici. Tout d’abord, vous pouvez utiliser l’attribut autocomplete="off". Nous avons récemment mis en œuvre une nouvelle stratégie pour suivre l’intention de cet attribut, et si ce champ était défini sur autocomplete="off", les options de menu sous le champ seraient masquées par défaut, ce qui améliorerait considérablement l’expérience utilisateur.
Je comprends que, en raison de certaines décisions prises par l’équipe Chrome, cela soit difficile pour vous ; nous avons discuté en interne de la possibilité de traiter quelque chose comme autocomplete="discourse" de la même manière que autocomplete="off", et bien que je ne puisse rien promettre pour le moment, je peux dire que c’est à l’esprit de notre équipe.
Il y a même quelque chose de mieux que vous pouvez faire. Pour que 1Password ignore complètement ce champ, nous devons indiquer qu’il est destiné à la recherche et non à la connexion. Vous pouvez le faire en attribuant au champ un attribut name="user-search" (ou id="user-search"). 1Password verra le mot « search » à la fin du nom ou de l’ID et évitera de suggérer des identifiants pour ce champ.
Voici à quoi ressemblerait le champ avec ce changement :
1Password ne ferait plus aucune suggestion pour ce champ. C’est une modification que vous pouvez apporter dès aujourd’hui à tous les champs de recherche similaires pour empêcher 1Password d’apparaître !
J’ai également remarqué un champ « adresse e-mail à tester » à la route admin/email qui bénéficierait grandement de l’utilisation de autocomplete="off".
Ce sont les problèmes que j’ai remarqués. Si j’ai manqué quelque chose, n’hésitez pas à me le faire savoir. Je suis ravi de continuer à en discuter ici ! Nous travaillons toujours à améliorer nos suggestions et à être plus précis quant au moment où nous apparaissions ou non.
C’est très utile, merci !
Nous nous attendons en réalité à ce que les utilisateurs saisissent leur propre adresse e-mail dans ce champ lors du test de leur configuration e-mail.
Oui, je recommande vivement cette stratégie, car je ne vois pas Chrome changer.
Merci pour tout votre travail acharné ! 
Quelqu’un a-t-il rencontré des problèmes avec 1Password sur son site Discourse récemment ? Je fais un suivi ici pour confirmer, car cela fait un an.
De mon côté, il semble s’agir davantage d’un problème de navigateur (Microsoft Edge) que d’un problème lié à Discourse, donc inutile d’en parler ici.
Ceci reste un problème en cours. J’utilise Safari v15 et la dernière version bêta de 1Password, et le problème persiste toujours.
Remarquez ici que lorsque je suis dans un champ de nom d’utilisateur sur la page d’administration des utilisateurs et que j’y clique, 1Password tente de s’activer.
Merci de partager cela, Matt !
Y a-t-il d’autres endroits où tu vois 1Password apparaître ?
La zone de texte ici est un champ de nom d’utilisateur, donc techniquement, 1Password devrait s’afficher là. Malheureusement, ce n’est pas ton champ de nom d’utilisateur en tant qu’administrateur lorsque tu souhaites modifier le nom d’utilisateur d’un membre, donc je comprends que cela puisse ne pas être idéal.
De plus, cela a été partagé avec l’équipe 1Password 
Merci encore de l’avoir partagé, Matt !
