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

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

I came to report this issue and understand @1P_Dave'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.

@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

@1P_Dave, 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.

@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

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

@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

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

Sounds good! 😁

-Dave