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

13

Comments

  • Joeri
    Joeri
    Community Member

    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
    TelFiRE
    Community Member
    edited October 2022

    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
    coorasse2
    Community Member

    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
    uooq
    Community Member

    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
    dburrows
    Community Member

    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
    pushred
    Community Member

    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
    dburrows
    Community Member
    edited November 2022

    (dupe)

  • MobyDuck
    MobyDuck
    Community Member

    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
    deguen
    Community Member
    edited December 2022

    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
    Wirah
    Community Member

    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
    jjxtra
    Community Member

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

  • nciiis
    nciiis
    Community Member

    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
    pieterv
    Community Member

    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
    comter
    Community Member
    edited February 2023

    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
    greystate
    Community Member

    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!

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

  • patriciav
    patriciav
    Community Member

    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
    shuggy1001
    Community Member

    @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
    patriciav
    Community Member

    @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
    comter
    Community Member

    @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
    patriciav
    Community Member

    @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
    yabdab
    Community Member
    edited July 2023

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

  • comter
    comter
    Community Member
    edited July 2023

    @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
    yabdab
    Community Member

    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
    comter
    Community Member

    @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
    yabdab
    Community Member

    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
    comter
    Community Member
    edited July 2023

    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.

  • 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
    edited September 2023

    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
    comter
    Community Member

    @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.