Disabling 1Password X for specific fields/forms (web developer question)

13»

Comments

  • jessie_vp
    jessie_vp
    Community Member

    Ok will do :)

  • ag_yaron
    ag_yaron
    1Password Alumni

    :+1:

  • ben_walsh
    ben_walsh
    Community Member

    I have an input field with autocomplete set to a UUID (to work around Chrome's insistence on autocompleting things set to autocomplete="off"), autofill set to "off", and the 1Password interface still appears and shows its suggestions, overlaying the UI that I have implemented on the field. It's massively annoying and feels a bit hostile -- as a developer I have made the intention very clear that I don't want the field interfered with, but I am being overruled.

  • @ben_walsh

    As Yaron mentioned in his post here, if the field contains key words like "username", "password", or "email" then you might still see the inline menu. Coding a field as autocomplete="off" will essentially force the inline menu to be minimized, but the icon is still visible. If you'd like to have 1Password ignore the field entirely, you can change the HTML attributes to contain search somewhere in the HTML id or name as suggested in my post here.

    Let me know if that helps?

  • osioke
    osioke
    Community Member

    Hello @ag_yaron and @ag_jarek, just following up on the issue mentioned in this topic here, here and here with certain fields on Discourse, it has mostly been fine, but it seems it has regressed a bit for some fields in Discourse:

    Any ideas what we can do to resolve this?

  • ag_yaron
    ag_yaron
    1Password Alumni

    Hey @osioke ,
    We looked into the recent code changes and there doesn't seem to be any regression here.

    We still respect the autofill="off" attribute when no password fields are present on the page, so that should still work. Here's a test page to demonstrate it: https://fill.scet.ch/username_like.html

    If that doesn't work well for you, it would be best to give us access to a test/demo page that replicates the structure and design of your live pages so we can investigate further. Feel free to send it to support+x@1password.com alongside a link to my reply here so we can connect the dots :)

  • osioke
    osioke
    Community Member

    For us at Discourse, our case is a little different. We explained our it here: https://1password.community/discussion/comment/568414/#Comment_568414. I guess I'll just go ahead and give you access to the test site as you mentioned.

  • ag_yaron
    ag_yaron
    1Password Alumni

    Thanks @osioke .
    We'll get right on it as soon as you send that email.

  • osioke
    osioke
    Community Member

    Awesome! I sent the email immediately after I posted that message.

  • ag_ana
    ag_ana
    1Password Alumni

    Thank you @osioke! Have you received a ticket number already?

  • ag_yaron
    ag_yaron
    1Password Alumni

    We found your ticket and I have already replied, Thanks Osioke :)

    ref: HXW-62924-395

  • AlexY
    AlexY
    Community Member

    Please give developers a way to get rid of the popup! It keeps attaching itself to everything that has "email" or "user" in it's [name} or [id] or even a label! It's been 3 years, come on!

    LastPass already has this!
    data-lpignore="true"

  • ag_yaron
    ag_yaron
    1Password Alumni

    Hey @AlexY ,

    As you've probably read throughout this entire discussion, this is quite a tricky situation that we're not fully confident about and are still debating whether or not we should add such a feature.

    For now, you can try one of the following solutions:

    • If there's no password field on the page, you can try adding the autocomplete="off" attribute to the field.
    • You can set the field as a search field and 1Password will ignore it.
  • AlexY
    AlexY
    Community Member

    @ag_yaron

    autocomplete=off is ignored by 1Password and type=search adds unnecessary UI element (the clear button), that requires CSS workarounds, not worth to deal with one little password manager.

    PS. And please spare the "we've been debating for three years". This thread is started by developers who know how software companies work on the inside. For 1P it's just a low priority annoying ticket that never even got to the product manager of the dev team. Have the guts to say "no" then

  • ag_yaron
    ag_yaron
    1Password Alumni

    @AlexY

    autocomplete=off will be ignored if there's a password field on the page or if there are other clues on the page that will outweigh that attribute.

    I assure you that this conversation/debate has taken place with our higher ranks and have yet to conclude. I will ask our development team to chime in here and shed some more light on the matter for you.

  • Hey @AlexY 👋

    I'm a developer working on our browser extensions and Yaron asked if I could add some thoughts here. I don't have any suggestions beyond what he shared already, but I did want to say a bit more about our thinking.

    First of all, this is absolutely something we're aware of as a team - feedback like yours is regularly passed to the development team, and around autocomplete attributes specifically, it's something that we discuss a lot. One change we made here recently (which I hope shows that we're not afraid of spending time here) is hiding the in page suggestions when we believe the attribute is correct. This has definitely helped in a number of situations, even if it unfortunately isn't enough for the sites you're working on.

    Looking beyond that, I don't want to say no to anything, because we really are still deciding what to do. The hard problem is providing honest developers with what they need while not reducing the functionality of 1Password on sites which work against us. This is a problem we have data for - we can see exactly how many of the sites in our test suite are using the autocomplete attribute incorrectly, and the numbers are significant. This means blindly trusting the attribute would make 1Password worse on a number of sites and is why we need to tread carefully here.

    I hope that helps. I don't have much more to share because we really are still discussing this and constantly taking small steps to see what impact they have. I'd be happy to answer any further questions though.

  • SPAppDev
    SPAppDev
    Community Member
    edited January 2022

    Developer and user here.

    This is so insanely stupid and frustrating. Make an escape hatch on the developer side.

    • Forms (non sign-in/registration) and UI keeps getting messed up in apps that I develop due to 1password
    • You're prioritising [spreading 1password across every corner of the web] over [not messing up other people's applications]
    • Any ML solution is inherently brittle. Quit referring to it as a magic silver bullet, it's just statistics and math.
    • Accept that some organizations will block 1password where it's a valid user form. It's fine. Let them be egotistical, not you.
  • SPAppDev
    SPAppDev
    Community Member
    edited January 2022

    1password blocks all my UI buttons in a popover. If I click the little 1password-icon to close it, it automatically closes the popover because the click-outside-detecter registers the button as outside of the popover. !#€O!I#J€!#€

  • Hey @SPAppDev, I'm really sorry if you think we've got the balance wrong here. As I hopefully explained in my last message, this is a really hard problem. I'll try to address each of your points one at a time to make sure I don't miss anything.

    Forms (non sign-in/registration) and UI keeps getting messed up in apps that I develop due to 1password

    This is a completely fair criticism. We work really hard to avoid this but we're not perfect. If you can share any example pages where this happens, we'd more than happy to take a look and see what we can change to make things better. This is something that should be solvable on our side and we can likely learn something from your site that can improve 1Password across the entire web.

    You're prioritising [spreading 1password across every corner of the web] over [not messing up other people's applications]

    I think I see this from a slightly different perspective. The number of sites that abuse some of the mechanisms you might use to disable 1Password is significant and breaks the workflow of many 1Password users. Since users of 1Password have explicitly chosen to install our extension, we want to give them a consistent experience across the web.

    Any ML solution is inherently brittle. Quit referring to it as a magic silver bullet, it's just statistics and math.

    I'm not sure if there's a specific post you're referring to but the problem here definitely isn't an over-reliance on ML. A lot of the logic here is handwritten and we carefully choose where ML is appropriate.

    Accept that some organizations will block 1password where it's a valid user form. It's fine. Let them be egotistical, not you.

    I think this is more than a bullet point, but the entire topic of this thread. I don't expect that we'll fully agree here but I hope some of our thinking is understandable.

    1password blocks all my UI buttons in a popover. If I click the little 1password-icon to close it, it automatically closes the popover because the click-outside-detecter registers the button as outside of the popover. !#€O!I#J€!#€

    I think this comes back to the first point. If there's an example you can share with us, please do - I'd love to fix that :)

    Hope all of this helps. These discussions are useful even if movement seems slow and I appreciate you sharing your feedback.

  • JontyMC
    JontyMC
    Community Member
    edited January 2022

    As others has said, this is pretty annoying. We have a web app form that 1password wants to autofill an address in. Narrowed it down to having the string "chapt" being anywhere in text near the input form, eg:

    <form>
    chapt
    <input type="text">
    </form>

    Possible solution - track how many users actually fill the field using 1password, then disable 1password on the field if it goes below a threshold. Have functionality to allow 1password users to complain that a field is not fillable.

    Opposite solution - allow an attribute to stop 1password from showing, then have functionality to allow 1password users to complain that a field is not fillable. Blacklist the site completely from this functionality if abused, based on not fillable complaints.

  • tinysalt4230
    tinysalt4230
    Community Member

    Third solution - allow users to manually map fields.

    It's not normal that this topic is taking so many years...

  • Hey @JontyMC / @tinysalt4230 👋

    We've definitely discussed three of those internally - adding a way to disable 1Password, having a way to send feedback to us, and providing a mechanism for manually mapping fields to items. We're not against any of those but we haven't moved forward with any of them yet.

    Tracking how users fill is a little tougher - never say never, but it would require a lot of work on our side. We'd have to do it in such a way that we don't learn things about the sites you're filling on. That's always been a big priority for us and is something we care a lot about.

    "chapt" is an interesting one. It looks like this was being incorrectly caught by "apt" which is often an abbreviation of apartment used for addresses. I've fixed this on our end so it should be better in an upcoming release!

  • tinysalt4230
    tinysalt4230
    Community Member

    Tracking how users fill is a little tougher [...]

    Tracking? You shouldn't track anything.

    Mapped fields should be saved only on user account (maybe I want to map field the way that is specific for me and works only for me? there are many situations about no one thinks about).

    If something don't work because wrong HTML, then users should be spamming that site till they fix it.
    You shouldn't try "autodetect and fix" broken websites because this not work and broken site is still broken.
    Let's fix all the Internet for all, not only for 1Password.

  • @tinysalt4230, in the case of tracking I was referring specifically to the suggestion @JontyMC made. Sorry if that wasn't clear!

    Agreed on mapped fields, maybe we could share these somehow but being able to create them locally is always what I've envisioned.

    While ideally I agree that sites would adjust their HTML to make filling easier, the truth is that a significant proportion of the web doesn't, and asking the site's developers to make changes isn't always successful. Not having the ability to adjust filling independent of a site's HTML would mean not filling on lots of popular sites so we have to some flexibility there. I hope that makes sense.

  • yabdab
    yabdab
    Community Member

    Having exact same issue. In my case the icon covers over UI element s like my tooltip icon.

    From the looks of this thread the developers are not adding what would be an insanely simple fix for site developers.

  • AnnoyedDeveloper
    AnnoyedDeveloper
    Community Member

    It still doesn't respect autocomplete="off" - this is beyond frustrating. Lastpass has data-lpignore, why doesn't one password? I am never ever going to use this product voluntarily given how much annoyance and pain this has caused users and developers and you don't
    seem to be doing anything about it...

This discussion has been closed.