I have many duplicate entries, because "Update Existing" is NOT the default.

soundsgoodtome

I've used 1Password for years, and I always install updates immediately. At some point, I started being asked to choose between "Create New" and "Update Existing" on a frequent basis. I never paid close attention—I naively trusted 1Password to know the difference between a new entry and one to be updated—so I've typically just hit enter, so I could get back to work.

Now I've discovered that since "Create New" is the default, I now have tons of unwanted, duplicate entries for log-in after log-in after log-in.

Respectfully, this was not well-thought-out. I think it's safe to say that for the vast majority of users, "Update Existing" should be the default. I frankly can't imagine why anyone would want (or need) to create so many duplicate entries; yet, I suspect the current default has created unwanted duplicates in the databases of many 1Password users.

AgileBits, can you please, please make "Update Existing" the default? I don't like the extra click required for each operation, and I frankly just don't want to have to think about this. If 1Password is smart enough to know that the current site is "related" to one that's already in the database, I don't even want to be asked what to do. I just want 1P to save it and let me keep working. And if the log-in is unrelated, I just want it to create a new one. I'd rather not be asked at all, but I understand that circumstances might dictate choosing "Create New." And that's fine; but it should be the option, not the default.

If you disagree that "Create New" should be the default for all users, then at the very least, can you please just make it an option we can enable in preferences?

Screenshot for reference:

---

1Password Version: 6.6.3
Extension Version: 4.6.3
OS Version: 10.12.3
Sync Type: Dropbox
Referrer: forum-search:update existing

littlebobbytables

Hello @soundsgoodtome,

The way 1Password works is it will default to Update Existing if it can:

1. Recognise an identifiable change password form.
2. There exists a Login item for the registered domain of this site.

In all other cases it will default to Create New.

Can you describe in a bit more detail please the scenarios where you're seeing this dialog and would expect it to be offering to update an existing Login item please as we will need to understand where this is happening before we can comment with any accuracy.

soundsgoodtome

I don't know what more detail I can provide. I'm just surfing the web and using 1P as I always have. I can't describe the exact circumstances, going back months or perhaps years, of each occasion on which 1P did NOT offer to Update Existing, when in fact it should. Obviously I didn't realize what was happening at the time.

But I now know this has occurred because when I review my log-ins, there are 2, 3, and 4 entries for numerous sites—duplicates which I'm having to go though and manually inspect in order to determine which are the old ones (i.e., the ones with old passwords) that are no longer needed. In other cases, the passwords are all current, but these are all different variations of the same web site—perhaps the "normal" log-in page, then perhaps a different version of the log-in page (sometimes sites allow you to log in from pages with different, extended URLS; the parent URL is still the same, but maybe I did some browsing before actually logging in; so the URL is slightly different from the main URL. 1P should recognize that it's the same web site, but it apparently doesn't, so it creates a new log-in entry).

I'm speculating that that's one, possible scenario, based upon some of the duplicates I've seen. Each case is different of course but I have many duplicates, and the circumstances are not identical from case to case.

AGAlumB

@soundsgoodtome: Certainly the URLs would help. I can't speak for lil bobby here, but I guess I'm confused if you're using 1Password to fill login and then choosing to immediately save another upon logging in. Ignore the part about discerning between new/update for a moment, that seems like a showstopper. At that point, we'd love to know a few key pieces of information so we can test (and hopefully reproduce) this and get it fixed, since we're not seeing this ourselves:

1. URL saved in the login
2. URL you're visiting when this happens
3. Do the login credentials saved in each case match exactly?

For example, I'd imagine if you just filled a username and password using 1Password, there would be no difference. However, there could be an edge case:

• Page includes only username
• Page includes only password
• Page only accepts part of the password — e.g. I've seen this enough that I've taken note, where a signup and login forms accept different numbers of characters

Let me know what you find!

soundsgoodtome

Hello. Thanks for your replies and for your willingness to help.

brenty, you wrote:

"I guess I'm confused if you're using 1Password to fill login and then choosing to immediately save another upon logging in."

No, I've never done that. I should reiterate/clarify that I'm attempting to "reverse engineer" what's been happening by examining the evidence. I've used 1P for many years, so I'm not a novice. A number of my passwords are also saved in Safari, so I don't necessarily need to use 1P just to log in to a given site. That varies.

But what I'm reporting isn't behavior that I observed as it was occurring. What I'm reporting is that I've looked at my 1P log-ins, and I've discovered that there are many duplicates that I certainly didn't intentionally create. As you know, sometimes web sites modify their URLs. It's possible that, for example, when I was prompted to change a password (which some sites do, which is maddening), perhaps the URL they present us with is slightly different at the time that 1P isn't triggered to Update Existing, so it Creates New.

(I'm speculating that this is one of several possible scenarios, because in some cases, the duplicates represent 2 or even 3 different passwords, spanning 2 or 3 years or more.) So, in hindsight, I'm baffled as to why, over time, 1P has been creating duplicates instead of updating those original entries. Under no circumstances did I ever intentionally direct 1P to create new entries. But it's certainly possible that when presented with the window asking me to choose, I simply hit enter, assuming that 1P was defaulting to the correct choice (i.e., "Update Existing"). But it seems that in many, many cases, it created new instead.

Now that I'm aware of all these duplicates, I'm noticing that sometimes, when I'm logging in to a given site, I get the "Create New or Update Existing" window, and even though I'm simply updating info on the same web site, 1P is defaulting to Create New. Now that I'm more aware of this, I'm clicking "Update Existing." But why should I have to? If 1P "knows" enough to give me the option, why can't "Create New" be the default, so that it does that more often than it does the other?

I've seen that window popping up for quite some time, now. But admittedly, I didn't always pay attention to it, because I assumed 1P was smart enough to know when a web site was new or wasn't. But the fact that I now have so many duplicates suggests that in fact 1P is not always making the right determination. (And I'll accept responsibility for not switching it to the other option. But again, if "Update Existing" had been the default, instead of the other way around, I wouldn't have these duplicates.)

I don't have a list of web sites to give you, where this has occurred, because I've only recently become aware that over time, these duplicates were being created.

But what I can do is this:

(a) Look for future examples I can give you.
(b) Look at the existing duplicates to see if any of those URLs might be helpful.

I'm working and cannot do (b) at the moment, but I'll try to do so within the next couple of days.

Thanks.

littlebobbytables

Hi @soundsgoodtome,

As you can imagine, when it comes to bug reporting it's all about the details :smile:

Whenever the extension sees a form being submitted that contains a password field it passes this information to 1Password because the extension does not have any actual link to your vault. 1Password reviews the page and then it checks to see if:

1. There is a Login item already stored that holds the same password.
2. The Login item matches on just the registered domain. When I say registered domain I mean that 1Password ignores subdomains so when you're on https://account.google.com 1Password is checking to see if the Login item has google.com.

If the password does not match any Login item stored in 1Password 1Password 1Password will ask if you wish to save, defaulting to Create New.

Change password forms are slightly different. If we recognise a form as being a password change form we default to Update Existing and then offer from a list of any Login items that match to the registered domain.

So different paths after the FQDN (Fully Qualified Domain Name) don't matter as well as a number of other factors.

This is why learning more about the events leading up to when 1Password incorrectly asks is important to understand why it happened. I certainly don't blame you for not being able to remember if we're talking about events in the past, I often barely remember last week but to have any hope of getting a good grasp on this we will still need as many details as possible. It might be a while before you have it happen but when you do what I would be very interested in learning are these sorts of details.

1. Was it a login form, registration form, reset password or change password form?
2. What was the URL for the page when it happened?
3. What was the URL stored in the Login item that should have matched?
4. If you allow 1Password to save a new Login item, do the username and password fields match the Login item it should have seen?

Now you may not be comfortable sharing all these details in our public support forums and that's fine, I have no issue if you would prefer to email us and continue the conversation that way when you've found an example we can dissect. So if you prefer you can contact us via support+extension@agilebits.com and the right people should see it.

Like all software 1Password isn't perfect and especially so when it comes to web pages. We like to believe we're pretty good but the fact is it's an amazing tough battle. Something as simple as recognising a password change form is silly difficult when we're talking about interacting with the actual HTML compared to a human being eyeballing the rendered page. Pages come in an amazing number of weird designs meaning we're always playing catch-up. As I said earlier though, it's all about the details though as without them we could do far more harm than good through random changes to the code.