Desktop client shows old state after saving changes

[benjamin-shen]

Steps To Reproduce

1. Create a secure note with some initial content
2. Edit the item with different content
3. Save the item

Expected Result

The client shows the new state immediately after saving

Actual Result

The client shows the old state until after the user navigates away and back

Screenshots or Videos

bitwarden.bug.mov

Additional Context

I was able to reproduce with different item types.

Operating System

macOS

(other users are reporting this on Windows and Linux as well)

Operating System Version

Version 15.1 (24B83)

Installation method

Mac App Store

Build Version

Version 2024.11.0 (33157)

Note: I'm not encountering this bug in the older release Version 2024.10.2 (32149)

Issue Tracking Info

• I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-14972

[SergeantConfused]

Hello @benjamin-shen,

Thank you for your report. I was able to reproduce this behaviour and have flagged it to the Engineering department.
Please feel free to post additional information, such as screenshots or a screen video recordings, if you wish.

Thank you again,

[bwbug]

@SergeantConfused I have found an issue that I believe may be related (and could possibly help with diagnosing the cause of #12022):

If you save vault item changes using a different client (e.g., a browser extension), then the WebSockets live sync apparently will push the old/cached state of the modified item to the Desktop app instead of pushing the new state. For example, change the name of a vault item to Revision1 in a browser extension, and observe that the change is not pushed to the Desktop app; then (without doing anything to manually sync the Desktop app) change the item name to Revision2 in the browser extension, and observe that the live sync now pushes the prior Revision1 change to the Desktop app (instead of Revision2 as expected).

If you believe that my observations are unrelated, please let me know, so that I can open a separate issue.

[papageno]

I also observed that newly created item does not immediately show up (tested in a folder) until "Sync" is manually triggered.

This issue exits in the latest versions of desktop client at least on macOS and Windows 11.

[BennytheDude]

Updated input after more testing: I am experiencing this same problem when I edit a login to move it to a different folder. Even when I click out and click back to the screen, the data may not be refreshed. But if I go back into edit for the login record, the correct data shows on the screen. Then if I click Save again, the data is updated in the main application screen.

Extraneous comment about other things dropped.

[bwbug]

the fact that I have no trash and a great many of my imported logins are showing in the trash is very disconcerting.

This seems to be a completely unrelated issue, not relevant to #12022. I would suggest that you post in the Ask the Community forum to get assistance solving the problem or verifying whether you are in fact experiencing a (different) bug.

[JaneX8]

This issue is seriously annoying. We get multiple complaints from employees who experience this. Please fix asap. It affects both most recent Mac and Windows Desktop Apps.

[l-c-g]

I have seen the same behavior on Fedora 41 with the Flatpak desktop client (there was some speculation in issue #12382 if this particular issue was only for Windows and Mac OS, which it is not):
Version 2024.11.2
Shell 32.1.1
Renderer 128.0.6613.137
Node 20.17.0
Architecture x64

After any change to an item, I need to force a UI refresh by either selecting another item or by entering the edit view again and then canceling out of it.

[JaneX8]

Yes, it's exactly that. The Desktop app (which is our main use case) is absolutely unusable.

Copying passwords after a change will contain the old password, not the new. Worthless.

[bwbug]

Issue persists in Desktop version 2024.12.0.

[valentingc]

I also experience this issue in the Desktop client version 2024.12.1.

[parcelcat]

Confirmed on Linux. This issue severely degrades usability and should be considered high-priority.

[JaneX8]

Indeed. It's unbelievable it's not directly fixed.