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:
Hi everyone! 
Jarek here from the 1Password extensions team. I spent a bit of time this morning poking around the Discourse trial instance @osioke got set up for us (thanks for that!), and here are my findings.
I took a look at this particular field and it looks like we’re not showing up anymore as of the latest 1Password X stable version. I added a test case internally to make sure we don’t show up here ever again! 
I confirmed that we were showing up here, and I’ve added a test case internally and made a change that will prevent that from happening (based on the fact that the label above the field mentions “invite”). Whenever the next 1Password X beta is released, give it a try here 
.
I found a field at the following URL that I unfortunately can’t do anything about on our end (admin/users/list/active route):
Our script to collect information about the page is gathering the following information for this field:
{
"htmlId": "ember921",
"htmlClass": "ember-text-field ember-view",
"isActive": true,
"opid": 5,
"placeholder": "username, email or IP address",
"type": "text",
"labelBefore": "Show Emails"
},
There’s nothing here that I can target to help 1Password understand not to show up in this field. For all it knows, this could be a login that needs auto-filled.
There are a couple things you folks can do to help 1Password out here. First, you can use the autocomplete="off" attribute. We recently rolled out a new strategy for how we attempt to follow this attribute’s intent, and if this field were autocomplete="off", the menu options beneath the field would be hidden by default and the UX would be vastly improved.
I understand that due to some decisions the Chrome team has made this is difficult for you to do; we have internally discussed treating something like autocomplete="discourse" the same as autocomplete="off", and while I can’t promise anything at the current time I can say it’s on our minds.
There’s something even better that you can do, though. In order to get 1Password to ignore this field altogether we’ll need to indicate that this field is intended for searching and not for logging in. You can do that by giving the field a name="user-search" attribute (or id="user-search"). 1Password will see the search at the end of the name or ID and avoid suggesting logins for that field.
Here’s what the field would look like with that change:
1Password would no longer make any suggestions for that field. This is a change you can make to any such search-y fields today to prevent 1Password from showing up!
I also noticed an “email address to test” field at the admin/email route that would benefit greatly from usage of autocomplete="off".
Those are the issues I noticed. If I missed anything please let me know. Happy to continue to discuss things here! We’re always working on improving suggestions and becoming more accurate about when we do and do not show up.
That’s very helpful, thanks!
We do actually expect people to put their own email address in that box while testing their email configuration.
Yes, I strongly recommend this strategy, because I don’t see Chrome changing.
Thanks for all your hard work! 
Has anyone had any issues with 1Password on their Discourse site recently? I am doing a follow up here to confirm as it has been a year.
On my end, it seems to be more of a browser issue (Microsoft Edge) than a Discourse issue, so no need to mention here.
This is still an ongoing issue. I’m running Safari v15 and the most recent 1Password beta, and it’s still happening.
Note here when I’m in a username field on the user admin page and when I click in, it wants to activate 1Password.
Thank you for sharing this Matt!
Are there any other places you see 1Password popping up?
The textbox here is a username field, so technically, 1Password should pop up there, unfortunately, it isn’t your username field as an admin when you want to edit a member’s username, so I see how this may not be ideal.
Also, this has been shared with the 1Password team 
thank you once more for sharing it Matt!
