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

reedmaniac

@jack.platten OK, but shouldn't the developers of a site have that power? Especially if 1Password showing up where it should not be is causing a bad user experience?

WayneAustin

Hi, just giving this thread a bump as it still seems to be a problem; I've had this issue raised to me on several occasions recently on fields and forms that are not related to authentication what-so-ever.

To fix the issue I simply removed keywords from the name and id attributes of the affected fields, in most cases it was the keyword 'id', i.e.:
from:
<input type="text" id="some-random-thing-id" />
to:
<input type="text" id="some-random-thing" />

This stopped the 1Password icon and autofill from happening, it doesn't have any adverse effects to the accessibility or usability of the form itself, nor lose any benefits provided by the browser, such as autocomplete.

Is there a list of keywords the 1Password plugin scans for on particular attributes to determine where to apply the 1Password tool/icon?
Maybe if you could share said list then we may have a better chance of avoiding 1Password from appearing where we don't want it.

Thanks in advance!

Zander_venn

As a note - this wasn’t an issue in the ui for the old extensions. That workflow was much clearer and easier to have control over.

Nhat_Nguyen

@reedmaniac I understand your concern, and we are considering putting a specific attribute to 1Password so developers can prevent 1Password from showing up on their site. However, it is not an easy decision as you understand that we might see 1Password stop working everywhere, so one of the solutions that we are adhering to and working hard to improve is enhancing 1Password's "brain" to help it works better. As 1Password gets smarter, it can better detect and fill in websites. I don't deny that 1Password sometimes appears where it is not welcome, but if provided with an example, we will have the data to teach 1Password to avoid it and similar cases altogether.

You can confuse 1Password by adding random string to the name or id attributes as suggested by @WayneAustin, but if 1Password can detect that it is on the login page and there is only one type = 'text' and type='password' fields, 1Password should still be able to deduce that it should save one as a username and one as the password.

greystate

It baffles me a little that you're that concerned 1Password might stop working on many sites?
The only developers I can imagine that would disable 1Password for actual fields are those that do all sorts of weird things anyway (for reasons we can't know or judge), like removing the ability to paste in the password field etc.

Also, as a long time 1Password user, I can honestly say that having 1Password pop up in places where it shouldn't is far more annoying than the few places where it doesn't work. So having a sure-fire way (sanctioned by the developers of 1Password) of preventing it for the occasional textfield would be lovely.

Nhat_Nguyen

Hello @greystate, when we give a tool to disable 1Password on a website to prevent it from saving and filling, which is the whole point of using 1Password, naturally we must be cautious. It is unclear why people want to stop 1Password from working on their sites as we never know their motive, but someone could do it in favor of another password manager.

mac232

As a user of the extension, there are many annoying places where the 1p icon shows up in a field where it shouldn't, possibly blocking some UI that I need to interact with. It's even worse when the 1p UI is trying to autofill stuff when it really shouldn't, and seeing this thread I'm starting to understand why it happens more than it should. Because the UI is clunky and unreliable, I can't really recommend using 1p to my mother who is semi-computer literate.

I understand the other need that you don't want annoying devs to also block autofilling when they shouldn't, but maybe another way is to allow you to easily right click any field to start the password filling system despite autofilling. Make it one click, where you have right-click -> fill username (suggested name) and right click -> fill password (suggested password). Or right click -> start autofill prompt.

Maybe make the fields 'glow' and don't put any icons, and open the independent 1p window from the browser toolbar would be another alternative. This way you don't have to directly modify websites and have a fragile system, and the 1p UI doesn't interfere with using the web UI as intended with blocking menus and icons on the website directly.

Also another thing is 1p could add specific tags of some sort to fields that devs can give as hints to 1p. Like "this is the real username input for login" , "this is the real email input" (for places that need both), "this is the main password input", "this is the OTP input", "real login button", "real cancel button", etc.

Also tags for new accounts, such as "new password" , "confirm new password", "new user email", "new user email confirm", "new user name", "submit account creation button", etc. Your tag system could also create a programmatic 'password conditions' thing so your password generator could automatically create passwords properly. Some places use very old systems as their backends, so they're forced to put silly conditions like min 5 to max 15 , certain legal or illegal characters, etc. If we had a standard that let us communicate those conditions programmatically it would make everyone happier.

That way people who don't want to block 1p, but make sure it works really well can make something better for everyone, and it can help your learning system improve as a data set. 1p could be a leader and make it an semi-open standard too and publish it on their website.

I work at a big tech company as a staff engineer, so if 1p made something like this, I would try to advocate our login team to adopt these tags & password requirement system to our web interfaces, since it should be fairly simple for them to add.

Zander_venn

"As a user of the extension, there are many annoying places where the 1p icon shows up in a field where it shouldn't, possibly blocking some UI that I need to interact with. It's even worse when the 1p UI is trying to autofill stuff when it really shouldn't, and seeing this thread I'm starting to understand why it happens more than it should. Because the UI is clunky and unreliable, I can't really recommend using 1p to my mother who is semi-computer literate."

the sad thing is that these are all issues introduced by the new browser extension. The old one was easier to intuit and less intrusive.

AnitaGraham

I'm a 1P user, and web developer who's noticed the intrusion of 1P into unexpected fields.

This seems to be an issue of who has control of the fields? The form developer or the one password developer .

As a user, the only thing I expect 1Password to do is to save/fill some limited data (username/password, credit card fields).
I don't want it to guess what any other field is, and try to fill it from a selection of my data. Isn't this a risk for the user? If they are not alert, or are typing ahead, or distracted then they risk 1P filling a field incorrectly, and having the data submitted.

And who hasn't blithely pasted something into a form, only to find that the focus was elsewhere or their password was still in the buffer because a ^C didn't work? (Not you? Well you are smarter, more alert and have more nimble fingers than I have)

I also think that the suggested solution of having a 1Password-specific data attribute on some fields has real problems.

1. That's a lot of fields that will have to have an attribute for 1Password, and one for lastPass and one for the next great thing to come along. Developers will be playing catchup, or we'll need another piece of code to control all the extensions in the specific way each of us would like.
2. What sort of fields is 1Password targetting? Perhaps being specific about how/which fields are targetted would allow the development of standards in field naming that both web developers and extension developers could work with. Aiming at all fields or having too-broad a target would be a problem.

Anita

alecbw

Chiming in on this thread, as it seems to be two pages of 1Password employees trying their hardest to not listen to community feedback.

Setting a specific attribute in the HTML elements to prevent 1Pass acting on those elements - say, data-disable-1pass=True- would ensure only the small percent of sites that implement the specific attribute would be excluded. I do not accept the suggestion that using an inappropriate type=search attribute is an acceptable solution.

1Password for Safari is breaking the contact form on my website, and I would like to avoid mutating all the id and name values in the hope that maybe that fixes the problem.

zomars

The only thing you're achieving by ignoring your community is to FORCE devs to use input type=search. You can't stop devs from actually blocking 1pass on their sites. You're just making it harder for everyone.

ystar

This is a real problem for our company as it pops up and requires hitting esc on form fields that have nothing to do with a username/password. I'm having our staff disable the plugin and we are looking for an alternative as this will end up costing us more in time than the value of the product. I sure hope 1password is listening. This is a really easy fix by allows us web developers to disable on fields we know don't required interaction with this plugin.

Dayton_ag

Hey all,

Thanks so much for your comments and feedback on this issue - we really appreciate it. There's always room for improvement, and the best way for us to improve is to get feedback like this.

As my colleauges have mentioned, we are sharing this feedback internally with the teams in charge of making these decisions. At the heart of those decisions is a fundamental desire to provide the best browser experience possible, and that involves considerations of a problem from all angles. We want to ensure that we're empowering users with easy-to-use tools that work wherever they need to fill credentials, while also giving Developers the tools they need to ensure that 1Password is a good citizen on their website.

Our approach involves endeavoring to teach 1Password in your browser to reason properly on a webpage to identify fillable fields without making itself an unwelcome guest, while also working with good web development practices.

I do want to assure you that your voice is being heard, and we agree with you that there needs to be a good way of ensuring that 1Password is as helpful as possible, without getting in the way. We really appreciate that you've taken the time to reach out and let us know that there's a gap here that needs filling, and we are working hard to determine the best course we can take to fill it.

btz1

1password extension is not respecting my text field with "autocomplete=off"
The result is the 1pass button in front of the input[text] value
These fields are used in an admin panel, here 1pass should not be used

Gif

Video
https://drive.google.com/file/d/14oz62Q4wHFdrTD3em1Z7ptodFMLF2CQY/view?usp=sharing

Jack.P_1P

Hi @btz1:

Thanks for sharing your additional thoughts. As Dayton mentioned, we're sharing this feedback internally, as we continue to balance empowering users to fill everywhere they they need to fill, while also giving developers the tools to help 1Password be a good citizen on their website.

Jack

carpii

I dont think adding a data attribute to suppress 1Password is the right solution. Then we have another data attribute to suppress lastpass, and keep adding them for each password manager.

I'm not sure what the exact solution is, but it's fair to say the 1Password detection seems a bit flawed.

It is not behaving as described earlier (ie, we are told autocomplete="off" should suppress 1Password, unless a password field is also present). This doesn't appear to be accurate

What I'd like to see is the detection heuristics to be predictable and properly documented, so web developers can understand why its appearing, and workaround it if needs be (for example by changing a fields name from username to something else).

zomars

we're sharing this feedback internally

Can you share it harder? There's been two years since this thread started.

Phoczur

type='search' seems to work on all browsers that I have tested and indeed prevents 1password from showing up. so that's good :) In my case didn't notice any negative effects of changing the field type.

However... 1password on chrome (mac (Big Sur), Chrome ver 102) breaks the browsers default autocomplete even on type='search' fields. This is not ok towards your users. On Safari it doesn't do that so I'm guessing that's a bug and not a feature.

arlomedia

In my case, I have a page in my system where project administrators can add and edit other project users, including editing their username and password fields. I commonly hear from users whose 1Password auto-filled their own saved login info into another user's page, overwriting the other user's login info.

This use case is what the "autocomplete='new-password'" attribute was designed for (https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion), so supporting that would be a logical, standardized solution. But as 1Password employees have stated above, they don't even support "autocomplete='off'" on pages that include a password field.

1Password employees have also stated that they prefer to gather info about a page and decide algorithmically whether to disable 1Password. I guess that's fine, but if a web developer says "please do not interfere with the function of this field," that should be a major factor in that algorithm.

arlomedia

In my case, I have a page in my system where project administrators can add and edit other project users, including editing their username and password fields. I commonly hear from users whose 1Password auto-filled their own saved login info into another user's page, overwriting the other user's login info.

This use case is what the "autocomplete='new-password'" attribute was designed for (https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion), so supporting that would be a logical, standardized solution. But as 1Password employees have stated above, they don't even support "autocomplete='off'" on pages that include a password field.

1Password employees have also stated that they prefer to gather info about a page and decide algorithmically whether to disable 1Password. I guess that's fine, but if a developer says "please do not interfere with the function of this field," that should be a major factor in that algorithm.

arlomedia

I suppose another part of the algorithm could be to not auto-fill a field if it already has content in it. But that wouldn't help when an administrator wants to add a new user.

travismlive

Hi @Jack.P_1P

I just want to say first that I'm not a developer so my comment here is probably just a preaching-to-the-choir sort of thing. I'm also not 100% sure that this would be relevant to every person's individual grievance in this thread... but back when I was using Lastpass I remember this was never an issue for me. Using the Chrome extension I was always able to disable autofill for either the full URL or the entire domain.

This is something I'd like to see in 1password.

But again, I'm not a developer and I don't know how the ways in which Lastpass and 1Password are different in regards to making autofill-disable something possible in 1Password like it is in Lastpass.

travismlive

Hi @Jack.P_1P

I just want to say first that I'm not a developer so my comment here is probably just preaching-to-the-choir sort of thing. I'm also not 100% sure that this would be relevant to every person's individual grievance in this thread... but back when I was using Lastpass I remember that this was never an issue for me. Using the Chrome extension I was always able to disable autofill for either the full URL or the entire domain. This is something I'd like to see in 1password.

But again, I'm not a developer and I don't know how the ways in which Lastpass and 1Password are different in regards to making autofill-disable something possible in 1Password like it is in Lastpass.

mohammad110

any updates to this? Grammarly has an awesome HTML attribute (data-gramm_editor="false) which disables the auto-correction on some fields. I hope this gets to 1Password too.

ctepeo

Hey, 1Password developers, there're already 2 years (oh my, just thing, two years!) passed since we, web-developers, started to asking you, developers from the another side of a product, to implement an attribute/flag for us which you gonna respect to help us, web-developers, make our users' experience better. We are not crazy to add it everywhere just because we can (like we don't do that with Last Pass), because why we have to? But we sometimes simply need it. Even more: we can always create custom elements with input-like behaviours and you'll not be able to handle this properly. We don't do this, because cross-app development has never been a battlefield between sides. We are actually in the same boat: we try to care about the same user. And we need your help.

Instead of helping us to make our users' lives better you're simply trying to keep 1Pass to pop up here and there, because if it's not shown, you think that users will be angry on you ("where's the 1pass i've paid for?!"). The biggest miss in this logic that your tool works over our code and we still decide what's important for a user and users still visit our code to get some actions done. We're not asking to block ability of a user to store something at 1Pass, they can always just open the app and add any data there directly, you know, but we're asking not to make our UI/UX ugly.

So when we decide what's better for a user, it's definitely our risks: it's our service in the end where user came, they're returning or not returning customers, the ones who gonna visit us again as not paying customers or not. That's our risks.

I also don't believe that you just can't handle a simple data-attribute flag which you choose by yourself. All these "try type=search" and "try autocomplete=off"... What do you mean under "try"? Is it randomised or your code is that unstable that you can't even guarantee any simple behaviour? These "if a page contains a password input attribute autocomplete=off will not work". Seriously, how do you look into eyes of your manager after you wrote that? We're here developers and understand processes not worse than you do from your side and that's nothing but shame.

@Jack.P_1P "empowering users to fill everywhere they they need to fill" that's what we choose, not you or a user. We add inputs, we specify these inputs' types, we add labels to them to explain users their meanings, then we validate the data at least twice (FE and BE) before we allow user to store the data we need. No one else, but we specify and control "everywhere they need to fill". And we here need a solution to be able to hide 1Pass icon from places where it makes no sense for our users. Not a "try type=search", or "try this...", but a solution and the solution is super straight forward: an attribute of your choice.

bsuvc

I'm running into this problem and it's very frustrating.

Is there a fix coming? autocomplete or maybe a data attribute or something?

beausmith

I too am looking for a solution to disable 1Password on forms where it should not be used.

I want to propose a win-win-win solution for 1Password, developers, and all users.

1Password should not be concerned that developers will abuse the ability to disable 1Password on various HTML inputs. 1Password should provide a means to disable 1Password which developers can use where they deem appropriate.

When a developer inevitably "abuses" the ability to disable 1Password, users will likely complain to the company/developers to ask them to remove the disabled functionality. To help these users make a case to the company/developers, 1Password can have a web page describing what the company should/can do to allow the users to use 1Password and why this is the right thing to do.

As a fail-safe to provide 1Password users full control, 1Password could add an app preference to allow overriding any disabled form inputs based on site url, or globally.

With this solution, 1Password extends trust to developers (who will do the right thing a majority of the time) and provide the 1Password users with the ability to ultimately control their experience.