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

Joeri

I have the 1Password input helper pop up in email fields for an ERP application. There is no use-case whatsoever the user wants to pick an emailaddress from 1Password when managing its customer data. Autocomplete = off is already set. 1Password should not show the menu. This is a super valid use-case to have developers 'know it better', simply because we do! Please fix asap.

TelFiRE

Is there for real not an easy way to deal with this? For freakin real? Are you kidding me?

There is NO password field on the page (why is that even relevant?), and autocomplete is OFF (stupid way to handle this but ok) AND STILL IT IS THERE, WHY?

coorasse2

After what has happened on https://1password.community/discussion/134948/1password-chrome-extension-blocking-onblur-event-bug I think I simply want to be able to disable 1password on my zip code fields.

uooq

Given that there's a HORRENDOUS bug right now where signup for our app is completely broken for users because you're swallowing the OnBlur event for email inputs... it would be REALLY FREAKING NICE if I could disable the field until you FIX YOUR BUSTED EXTENSION!!!

Seriously, total HUBRIS to assume that you can make statements like "Our primary concern remains that developers will use this power to disable 1Password in the browser in places they shouldn't". Because of course YOU are perfect and WE are hacks!!!!

dburrows

I don't really get the logic here

• You don't want to respect the autocomplete setting
• but there's a load of workarounds any bad actor can do to turn 1Password autocomplete off anyway
• so really all you're doing is punishing web developers who are working in good faith and trying to follow web standards
• Bonus: you are completely destroying keyboard navigation in some cases so all this is probably having a bigger effect on people with disabilities

As a long time user of 14 years (!) I've recommended 1Password to my friends literally hundreds of times, I expect better, please follow the standards

pushred

Providing another example of an input where the 1Password is triggering (icon only) where I wouldn't expect it to:

<input
  aria-invalid="false"
  autocomplete="off"
  name="query"
  placeholder="Account ID, plan ID, plan name, or Custodian Account number"
  type="text"
  class="MuiInputBase-input MuiOutlinedInput-input MuiInputBase-inputSizeSmall MuiInputBase-inputAdornedEnd css-19qh8xo-MuiInputBase-input-MuiOutlinedInput-input"
  value=""
/>

I tried trimming down the placeholder to see if one of those words might be the culprit, but it seems so long as there is at least 2 words it triggers, regardless of what they are. Coincidentally this happens to be a search field so I was able to disable 1Password by associating it via ARIA to a heading that contained the word "Search".

dburrows

(dupe)

MobyDuck

Just wanting to add my voice (as both web developer and a long time paying 1Password user) to the multitude - having some control over the fields 1Password fills is sorely needed as its own heuristic approach simply isn't reliable enough. I've just fixed an issue where 1Password put half a 2FA code into the correct input, and half in a completely unrelated input (even though the second input has autocomplete off). It's been making signing into a work app unnecessarily annoying for ages.

I resolved the issue by suffixing the second input ID with '-search' (thanks to those in the thread who suggested that).

developers will use this power to disable 1Password in the browser in places they shouldn't

Developers already have this power, it's just that we have to use ridiculous hacks to wield it. We'll work out ways of getting round these things when we have to, you're just making life harder for users and developers.

deguen

For those interested, here's a short snippet to disable 1Password on your site. Place the script at the top of your body before other content. It will console.log when you click on <inputs /> 1Password would otherwise inject. Should work on most browsers (firefox, chrome, etc.).

  <body>
    <script type="text/javascript">
      // Remove 1Password from page
      new MutationObserver(mutations => {
        for (const { addedNodes } of mutations) {
          for (const node of addedNodes) {
            if (node.tagName === 'COM-1PASSWORD-BUTTON' || 
                node.tagName === 'COM-1PASSWORD-MENU') {
              node.parentNode.removeChild(node)
              console.log('Removed 1Password') // TODO: Remove
            }
          }
        }
      }).observe(document.body, { childList: true })
    </script>
    <!-- rest of your app -->
  </body>

Wirah

How on earth is this STILL not fixed years later.

All we need is a way to prevent 1Password injecting itself into irrelevant inputs (yes that includes the icon too).

Once again I have no password inputs on the page, autocomplete="off", I'm using obfuscated field names so 1Password doesn't assume anything.. and the field STILL gets injected with the 1Password icon.

<input class="TextInput_input__YmWKL" type="text" name="aaaa" autocomplete="off" inputmode="text" value="">

Please just give us a data attribute we can use to prevent this icon appearing, or recommend a method that works.

jjxtra

autocomplete="off" just does not work, at least in Firefox? This a bug or by design?

nciiis

I can't believe this is still a problem. How do we stop 1Password from appearing on forms which are obviously not used for logging in?

pieterv

I understand — and even appreciate — 1Password's ability to remember a variety of facts about me and my accounts, and fill-in those details automatically. It's useful functionality, and I'm grateful for it when it's relevant.

One place where it's distinctly not relevant, however, is in administrative backend interfaces. Lots of forms, editing common information like names, emails, and addresses of other people. In those cases, the 1Password UI is an encumbrance — one that the developers know from the outset won't be useful (except for a vanishingly small fraction of the time), and one which should be disabled.

We developers tell the browser not to track these inputs with autocomplete="off", since that's the standards-compliant indicator. We can tell LastPass to ignore the input using data-lpignore="true", since they've decided not to follow the standards (by default; there's a configuration option). 1Password's lack of provision for these use cases is incredibly frustrating, and tarnishes my perception of the product.

comter

Looks like the newest version of the browser plugin (2.7.0 on Chrome at least; released Feb 9th, 2023) now supports the data-attribute of data-1p-ignore. This removes the suggestion popup and the 1password icon in the input field.
<input type="text" id="username" name="ig" data-1p-ignore>

https://developer.1password.com/docs/web/compatible-website-design/

-the purring dork

greystate

Great! Took a couple of years, but looks like there is now a way 👍

As the OP, I would like to thank everyone for chiming in 🙌

If you come here ripping your hair, looking for a solution - check out comter's comment above for a link to the docs on the data-1p-ignore attribute!

steph.giles

Thank you for sharing @comter, let us know if you have any questions!

patriciav

i wrote a whole comment, but then your terrible UI made me signup for an account, even though there was already a post button, with no indictor that i would be redirected and lose my comment.

i suppose that's about inline with how 1password is handling this entire thread/bug/lack of understand of how the internet and good development works.

It is absolutely insane that your buggy/unpredictable browser extension will do stuff like, autofill fields it likes, or show icons in places which COVER the input that users are putting in, and your only solution is to make sure there is no password field anywhere on the form, or to make the inputs type=search? you are aware that many accessibility tools use the type attr of an input to determine how to help the end usser use that field. not to mention it's syntactically trash to do something like that, it's invalid html, and just plain outrageous.

or, just put "search" as part of the input name or id. Why yes, let me, once again, make my page less accessibly, and rename a field/property for my entire stack of my web app, because your inane "logic" is trying to "guess" where our end users might want auto complete.

your plugin has caused nothing but trouble for my end users and a simple attr option, like lastpass has, would solve at least 80% of the concerns in this thread, that has been going on now for over 2 years.

Finally... to say that you don't want to allow devs to turn disable your extension from interacting with their site, is... once again, outrageous. I can assure you, no one wants auto-fill/autocomplete where it doesn't belong. What's the worst that can happen? someone has to look up their password in their vault/whatever, instead of clicking a button? ohhh nooooo. there are FAR more usecases where it's a bigger security risk to have the password/option to autocomplete something, then there is to be able to turn it off as a developer.

shuggy1001

@patriciav as much as I don't want to stick up 1P here and yes, this issue was around for much longer than it should have been, I think you might have missed the comment a few before your own that explains that this is now possible using the data-1p-ignore attribute

patriciav

@shuggy1001 :O oooooh dang, thank you for pointing that out!!! I scoured the first 2 pages of this discussion looking for a real solution, and then this 3rd page for replies from 1password with anything new, and totally missed the 1 comment with real information.

How is this not documented? posted about? googling that attr gives zero relevant results lol.

thanks very much for the tag/pointing this out. will save me a lot of headaches! now... to figure out a good way to integrate this into my app efficiently...

comter

@patriciav @greystate Here's a little jQuery snippet that will quickly and easily add the data-1p-ignore attribute to any text or password inputs.

https://codepen.io/comter/pen/BaOxxyM

-the purring dork

patriciav

@comter oooh slick, and 1 password will pay attention to it, even if it's added after page load? i was expecting it to have to be on the page when it's initially rendered for it to be picked up properly. that's great news. will make for a more more centralized solution!

yabdab

data-1p-ignore does not seem to work on password type inputs in Chrome, Safari or Firefox

comter

@yabdab I can confirm that in Chrome version 114 on Windows 10, the password input field correctly does not show a 1Password input suggestion with data-1p-ignore set on the password input field. Can you let me know what OS version, browser(s) and 1Password browser plugin version you're seeing issues with?

yabdab

Looks like a bug of sorts. If you include an id parameter in the input , then the data-1p-ignore is not carried out.

See here: https://www.yabdab.com/1password

Safari: Version 16.5.2 (18615.2.9.11.10) Ventura
Firefox: 115.0.2 (64 bit) Ventura
Chrome: Version 115.0.5790.114 (Official Build) (arm64)

comter

@yabdab That is in fact a bug. I did a bit more testing and worked out a test table (and possible workaround) that can be found at https://www.comter.codes/data-1p-ignore-test/ and I also updated the jQuery snippet that I posted above to include the bug notice and workaround.

@steph.giles can you check on this issue?

yabdab

Found another fringe case ...

<label>
<span>Password</span>
<input type="password" name="password" data-1p-ignore />
</label>

See here: https://www.yabdab.com/1password

comter

I've updated the test table at https://www.comter.codes/data-1p-ignore-test/ with the additional fringe case. I also found that nesting the label wrapped input in a form tag will make 1Password ignore the form field correctly.

steph.giles

Hey @comter, @yabdab,

I'm sorry for the delayed response, I have reached out to the team for advice on this one and will let you know when I have any more information.

ag_michaelc

Hi @comter @yabdab et al. I just wanted to let you know I've resolved the issues you reported with the 1pignore attribute. This will be fixed in a future update. I appreciate the handy test site! 🙂

ref: https://gitlab.1password.io/dev/core/core/-/merge_requests/19267

comter

@yabdab It looks like v2.16.0 of the 1Password browser plugin has taken care of all the issues that were listed on my test table. Can you confirm that your example is also working correctly now?

Thanks @ag_michaelc and @steph.giles for dealing with and fixing the issues.