As a web developer, how can I disable 1Password filling for a specific field?

greystate

I am a web developer and I sometimes have a field in a form (e.g. inside a CMS) where it makes no sense for 1Password to pop up, and where it's actually causing the editors problems to keep dismissing the popup.

Is there a data-attribute or similar that I can use to tell 1Password not to bother with that field?

Thanks,

/Chriztian

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:html

ag_yaron

Hey @greystate ,

We're constantly working on improving 1Password's logic so it would know when to show up and where not to, but this is, as you can imagine, a never ending task :)

If the page contains no password fields, then adding the autocomplete="off" attribute should suffice. However, if there is a password field on the page then 1Password will ignore that attribute. The best course of action here would be to collect some page details for us so we can teach 1Password not to show up on that page anymore on our side.

greystate

Thanks @ag_yaron

I can imagine, yes :)

I've even tried with an HTML document consisting of a single form with a single input field (type=text or type=email) - 1Password pops up regardless of having the autocomplete="off" attribute on or not.

Was really hoping there was a sure-fire way, along the lines of the meta tags you can add to tell an iPhone not to detect phone numbers etc. - but it doesn't sound like that.

(The originator for this is a plugin inside a CMS so I can't really supply any meaningful details as they're ever-changing, depending on the many combinations possible).

/Chriztian

ag_yaron

Thanks for the additional info @greystate .

Perhaps if you can collect some details from such a page we can examine it and see what can be done, even if the page always changes. It's worth a shot :)

Here's how to collect the details on a page with 1Password X in Chrome:

1. Right-click the 1Password extension icon on the top-right corner of your browser and select "Manage Extensions".
2. Turn on the "Developer Mode" toggle on the top right side of the page.
3. In the center of the page where you see the extension's details, click the "Background Page" link.
4. A new window will open. Select the "Console" tab at its top, then click the bottom part of the console so you can write in it.
5. Type in the following and hit Enter afterwards: localStorage.setItem("devtools", "Y")
6. Close Chrome completely, then relaunch it and unlock 1Password X. Now, when you right-click the 1Password X icon on the top right corner, you should see a new menu option called "Developer Tools", which contains the "Collect Page Details" option.
7. Reach the page in question, collect the page details, copy them into a text file and send them over to us at support+extension@1password.com with a link to this forum discussion and a short description.

If you prefer not to do that, it is also fine, but I hope you will :)

greystate

Great - no worries, I'll do some digging and get some details for you to scrutinize.

Thanks!

ag_yaron

Thank you, we appreciate it :+1:

Hacksore

Reviving this thread as it is sort of pertains to what I am experiencing now.

In my example below GitHub expects the user to have autocomplete access here for convenience.

Lastpass has the "data-lpignore" attribute to stop the field(s) from triggering the manager. Is the stance behind 1password not offering something similar driven by a security concern?

I'd prefer not to have my 1password trigger here as I don't want to input anything sensitive by accident. I can't really tell GitHub to turn off autocomplete as I'd imagine that's more a feature, not a bug :chuffed:

I appreciate any feedback or ideas regarding this and hopefully, something that can be done.

Code for the input:

<input class="form-control input-contrast input-sm" type="text" id="input_0" required="" name="inputs[client_id]" value="blah">

Nhat_Nguyen

Hello @Hacksore,

Currently, 1Password doesn't have a custom attribute to inject in a specific input field to prevent it from showing up. Instead, it does its best to determine where it should appear. It is not perfect now, and it does sometimes appear where it should not. However, 1Password is improving as we are teaching it to be smarter.

I have a few projects on Github, but I don't use it much. Could you please let me know the option to get to the popup in your screenshot? I will do some tests and get back with what I find.

Best regards.

Hacksore

@nhat_1P Here is a demo repo to fork, hope it helps.

https://github.com/Hacksore/1passwordx-popup-issue

• Unlock password vault
• Fork code:

https://github.com/<username>/1passwordx-popup-issue/actions/workflows/example.yaml

• Run workflow
  

• Click the text field

ag_jarek

Hi @Hacksore! Jarek here from the Extensions team 👋

I agree that 1Password's suggestions likely aren't of much use for this field, and it would be best to avoid showing them here. I've made note of both that and your request for an attribute to tell 1Password not to show up internally.

In the meantime, the best solution we have to offer here would be adding the autocomplete="off" attribute to the field. That'll prevent 1Password's suggestions from automatically popping up, leaving just the icon in the field (much less obtrusive).

Thanks for bringing this to our attention, and if you bump into anything else please do let us know! :smile:

nthoftype

This shouldn't be a hard thing to accomplish. Obviously you (1Password) are looking for inputs on the page, why not just check if that input has a data attribute (could be anything, like data-1password="false") and if that attribute exists with the given value, don't display the icon/popup.

ag_yaron

Hey @nthoftype ,

As ag_jarek mentioned above, you can add the autocomplete="off" attribute to fields you don't want 1Password to show up in, and 1Password will respect that if there is no password field on the page.

Does that not satisfy your use case?

tibineagu

Hi 1password team,

Thanks for all your great input.

The amount of thought you put into helping us debug and provide troubleshooting data is astounding.

That being said, we have a situation where the 1password X prompt is rendered on an input that has autocomplete="off", AND there are no input type="password" elements on the page.

The prompt is rendered on the THIRD element in the array (the one that's active).

The output from the developer tool is below:

{
    "unparsedUrl": "[edited]",
    "title": "[edited]",
    "frames": [
        {
            "fields": [
                {
                    "htmlClass": "inner typable",
                    "opid": 0,
                    "placeholder": "Search",
                    "type": "text",
                    "labelBefore": "[edited]"
                },
                {
                    "autocompleteType": "off",
                    "htmlClass": "inner typable",
                    "opid": 1,
                    "placeholder": "Search",
                    "type": "text",
                    "labelBefore": "[edited]"
                },
                {
                    "autocompleteType": "off",
                    "htmlClass": "inner typable",
                    "isActive": true,
                    "opid": 2,
                    "placeholder": "Type a location",
                    "type": "text",
                    "value": "London, United Kingdom",
                    "labelBefore": "[edited]"
                }
            ],
            "forms": [],
            "origin": "[edited]",
            "title": "[edited]",
            "pathName": "[edited]",
            "uuid": "54dqj2"
        }
    ]
}

ag_chantelle

@tibineagu

autocomplete="off" will never cause the icon to disappear; it only impacts whether or not the inline menu is expanded by default. You've redacted the label on the third field there, making it hard to say why we’re showing up, or whether (or not) we should be.

If you don't want 1Password to show in the field, at all, I previously shared some suggestions in my post here that you may also find helpful.

xtfer

It would seem that the obvious solution is to ignore fields based on a custom 1password data attribute, ala Lastpass. All this faffing around with other attributes in the hope that 1password will somehow work it out is crazy. "Try these attributes and maybe it'll work plus you'll lose some other functionality" is not a solution.

ag_yaron

Thanks for chiming in here @xtfer ,

I've forwarded your input to the team.

ref: dev/core/core#4300

gnommer

Well, I also have hard time understanding why you won't just add ignoring some specific data attribute. Especially when autocomplete="off" is not causing 1p icon to disappear.
But ok, your choice to make devs life harder, we have to deal with this ;). I am facing similar issue as @tibineagu - no password field, but icon keeps appearing in one input. Hope this info helps you make 1password better, let me now if you need more details.
<input name="city" autocomplete="off" type="" id="locationCityInput" class="form-control">

gnommer

next one:
<input name="query" autocomplete="chrome-off" type="" class="mr-2 mt-1 form-control">
There is no word "password" in form too (or even in whole DOM)

ag_yaron

Thanks for the additional info and examples @gnommer , much appreciated!
I've added it to the report that was already filed. :+1:

dhughes

Is there any update on this? I too support the idea of a data- attribute on form elements to keep 1password from showing up for that specific field. Another example of this is on adwerx.com, where I work. If you go to adwerx.com, look for the "Target by Zip Code" section and click "Check Availability" you'll get a popover dialog with two fields "Your Name" and "Your city, state". The second field uses google's APIs to list city/states that match what you're typing.

To reproduce the problem, type a name in the first field and start typing a city in the second field. You'll get a list of suggestions. As soon as I hit the down arrow to select one of those suggestions the 1password dialog pops up and obscures the list. It's really quite jarring.

If we could just add a an attribute to the field like data-disable-1password="true"` that 1password ignores, then life would be easier. Failing that, maybe let advanced users specify something in the plugin settings to ignore specific CSS selectors so that individuals can shut it off?

I totally get wanting to make 1password smarter, but, as you said above, that's a never ending task. My wife already uses LastPass. I'm invested in 1Password, but this is the type of thing that encourages users like me to consider switching. It's important and should be addressed.

Thanks!

ag_yaron

Hey @dhughes ,
Thanks for the information and additional feedback here, I'll add your voice to the feature request report and ask if there's any news on it.

osdiab

I too am having this problem - we have a country select combobox written with Downshift, and for some mysterious reasons 1Password keeps on trying to autofill it, even if autocomplete="off", which makes basically 0 sense. Aggreed with all the others, that it seems bizarre that 1Password is both resistant to A) making a disable data- flag and B) keeps telling us to use autocomplete="off" when that doesn't actually seem to work.

B2B enterprise app so can't just send a link to demonstrate the problem, but I can give access if you request!

ag_yaron

Thanks for chiming in and sharing your experience @osdiab

wottpal

Same issue. 1Password is a little bit too aggressive in its popup logic. Web-Developers know best when disabling 1Passwort-Autofill is appropriate. Maybe as a little Christmas present? :P

zomars

Same issue here, we only have a text field with name=username but no password and 1 password keeps popping up regardless of autocomplete attribute.

ag_chantelle

@wottpal - a Christmas present would have been nice, but we're still working on this. Thanks for adding your voice here. :smile:

ag_chantelle

@zomars

Unfortunately, due to rampant misuse across the web, we can't guarantee that the extension will follow the autocomplete attribute 100% of the time.

Using an HTML input type="search" should be a guarantee that we wouldn't show up, but this does inform browsers that it is a search field and cause them to react differently. For example, many browsers will display an icon in and clear the field if the user hits esc. Here is an example of a search field that will never display the 1Password inline menu: https://fill.dev/form/search

Eli24

can we render the input first as input type search then when click, change the input type to password again?

ag_chantelle

@Eli244

Theoretically, yes. That said, an HTML id or HTML name starting or ending with search would also be something you could do without changing how the field is displayed and greatly improve the chance that we don't consider it interesting.

reedmaniac

Your suggestions to enforce a disabling of 1Password on an input field is to make it an input of type "search" OR add a prefix/suffix of 'search' to an Input element's id or name attributes? Seriously?

The first is bad HTML and the second will only "improve the chance" of 1Password not appearing. Developers should not be hacking their forms to have a password manager's extension disabled consistently and easily.

Jack.P_1P

Hey @reedmaniac:

This overarching subject is something we continue to have discussions on internally. Our primary concern remains that developers will use this power to disable 1Password in the browser in places they shouldn't. I've added your feedback to our issue we have on this.

Jack