Bug with conflicting field edits between 1Password desktop and browser plugin

O2024

Hi, I’ve noticed a long-standing issue where changes made in 1Password’s desktop app and browser plugin at the same time cause one of the changes to be lost. Does anyone else experience this, and could 1Password address it?

The Problem: If you edit one field of an item in the 1Password desktop app (Windows 11) and at the same time, edit a different field for the same item in the Firefox plugin, one of the changes gets lost.

Example:

1. You’re adding both MFA (OTP) and a Passkey to your GitHub account using 1Password.
2. First, you add the MFA OTP using the 1Password desktop app but haven’t saved it yet.
3. Then, in the same session, you add a Passkey and use the 1Password browser plugin’s "Update Existing" feature to capture it.
4. You go back to the 1Password desktop app and save your OTP entry.

Expected Behaviour:
1Password should only update the OTP field in the desktop app and the Passkey field in the browser plugin.

Actual Behaviour: The Passkey field gets lost, even though both changes were to different fields. It seems the desktop app overwrites the entire item, ignoring the browser plugin's update. The history feature also doesn’t help as updates made within the same second are shown out of order, making it difficult to find the lost Passkey.

Suggested Fixes:

• Conflict Check: When saving, 1Password should check if a newer version of the item exists and only modify the fields that were edited.
• Field-Level Merging: Instead of overwriting the entire entry, only update the specific fields that were changed. This would avoid most conflicts and data loss.
• Conflict Warning: If a field was changed elsewhere, display a warning asking which version to keep or offer a merge option.
• Optimistic Locking: Implement a system that locks the entry during a save operation to prevent race conditions and alert the user if a conflict occurs (combined with above conflict warning).

Would appreciate any feedback from others or insights from the 1Password team!

Thanks!

Dave_1P

Hello @O2024! 👋

Thank you for reaching out! I'm sorry that you misplaced a passkey when editing the same item, at the same time, using both the 1Password desktop app and 1Password in the browser.

1Password currently uses a "last edit wins" system when it comes to sync conflict resolution. While this works for the majority of scenarios there are some edge cases where better handling would be desirable. Your example of editing the same item using two different instances of 1Password at the same time is one such edge case. The team is discussing ways that we can improve conflict resolution going forward and I've added your comments to that conversation.

For the time being I do have some suggestions:

1. When editing an item, update that item using only one instance of 1Password at a time.
2. If you do accidentally edit an item using two different instances of 1Password, at the same time, and need to recover data then you can do so using item history: View and restore previous versions of items

Hopefully this is something that can be improved in the future.

-Dave

ref: /b5book/-/issues/1064

AJCxZ0

I came to report this issue and understand @Dave_1P's advice, however there is a user interface/experience failure involved.

When setting up a new account, I have the desktop client open so that I can modify and add to the item created during the initial sign-up process, saving all the changes only when the account setup is complete.
The account setup process usually involves configuring 2FA/MFA/OTP during which the plugin may be extremely helpful by offering to save the key and fill the code, which is of course an offer I cannot refuse. This results in a desktop client with unsaved edits and a one-time password which will disappear the moment I click [Save], with the only alternative being to [Cancel] and loose all my edits.

Since winding back time to just before I agree to the plugin saving the OTP so that I can click [Save] on the desktop client is too advanced a feature even for 1Password and a robust sync and merge process with simple and easy conflict resolution for multiple clients is very hard, perhaps the best solution is for the plugin save process to optionally prompt the user to save any outstanding changes before saving until the user disables the prompt.

Another approach which addresses a broader case would be the ability to restore selected entries from a previous version of an item to the current version.

Dave_1P

@AJCxZ0

Thank you for the feedback. You wrote:

When setting up a new account, I have the desktop client open so that I can modify and add to the item created during the initial sign-up process, saving all the changes only when the account setup is complete.

Can you tell me a little more about this? What information are you saving into the item using the desktop app that 1Password in the browser doesn't save automatically right on the page?

I look forward to hearing from you.

-Dave

AJCxZ0

@Dave_1P, The process I follow starts with the sign-up form on a web site. After filling the various forms (often with autofill help from 1Password), I accept the plugin's offer to save these fields. If the web site doesn't direct me to authentication settings, then I navigate there.

Next I open the desktop client so I can clean up the mess which the auto-save feature usually makes including manually moving things I want to keep out of the undesired "Saved on..." sections, then removing them and the unwanted saved fields in them. I often add fields such as email (which may not have been included), UID, handle, API keys, set tags and either reduce or replace the web site filed with a login page and sometimes adjust the autofill behaviour.
Note that even where possible to change details via the plugin, the fact that the interface disappears as soon as the pointers leaves it - precluding the ability to copy anything outside - makes doing so impractical.

It's usually around this stage when I'm setting up TOTP and passkeys that the plugin picks up the QR code and helpfully offers to save.
Accepting that offer saves that key, but effectively renders all the changes I've made in the desktop client unsavable, else is lost when I subsequently save my changes in the desktop client.

Dave_1P

@AJCxZ0

Thank you for the detailed explanation of your workflow! I've shared your comments with the team.

For the time being, although it's not the best workaround, I recommend that you first save everything (including an QR code and passkeys) using 1Password in the browser before you start editing the item in 1Password for Windows. Or save the item using 1Password for Windows before you do more work with 1Password in the future.

Hopefully conflict resolution can be updated and be made more sophisticated in the future.

-Dave

AJCxZ0

Thanks for the practical suggestion, @Dave_1P.
I take no offense at the suggestion that I would ever use Windows, despite how undeserved and hurtful the repeated implication is.

Dave_1P

@AJCxZ0

My apologies for the misunderstanding, I assumed that you were using Windows since this thread is in the Windows category. However my comments apply to the Mac version as well. 🙂

-Dave

AJCxZ0

@Dave_1P No apology needed. My comment concerning your implication that I used Windows was entirely for humorous purpose (despite text not conveying tone) and the suggestion itself was quite reasonable.

Your insinuation that I am a Mac user, however, is unforgivable. I demand satisfaction with pistols at dawn.

I followed your suggestion to let the plugin handle the creation and update of the Login item earlier today, including TOTP and Passkey, then cleaned and completed in the desktop client.

Dave_1P

Sounds good! 😁

-Dave