Item list still shows an item after it is moved out of the viewed folder

[ChrisonSimtian]

Usage Information

• BitwardenSharp dbbf4df (develop)
• .NET SDK 10.0.400, net10.0
• Avalonia 12.1.1
• Bitwarden CLI 2026.7.0
• macOS 26.5.2 (arm64)

Description

After dragging an item out of the folder currently being viewed, the item remains in the middle
list. The move itself succeeds — the item is in the destination folder in Bitwarden — but the list
still shows it under the folder it left.

Reproduction Steps

1. Unlock and open the vault browser.
2. Select a folder in the tree so the middle list is filtered to it.
3. Drag one of its items onto a different folder.
4. Observe the middle list.

Expected Behavior

The moved item disappears from the list, because it is no longer in the folder being viewed.

Actual Behavior

The item is still listed under the original folder.

Regression?

No — present since folder management was added (422baed).

Known Workarounds

Press Refresh, or reselect the folder.

Notes — where to look

VaultViewModel.MoveItemsToFolderAsync routes through RunFolderOperationAsync, which does call
ReloadPreservingSelectionAsync() on success, so a refresh is being attempted. Unverified
candidates for why it does not take effect:

• RebuildFolderTree() calls Folders.Clear(), which can null the TreeView's bound
  SelectedFolder. ApplyFilter() then runs unfiltered, and the selection is only restored
  afterwards by path — if that lookup misses, the list stays on "all items" and the moved item is
  legitimately still shown, just not where the user expects.
• A race between UpdateItemAsync and the subsequent SyncAsync()/GetItemsAsync(), returning
  the pre-move state.

Worth confirming which before fixing — the two need different remedies.

Related: #2, #4.

[ChrisonSimtian]

Proposed approach (from @ChrisonSimtian)

Right — MoveItemsToFolderAsync reloads on success, and that is the whole problem: the view
does nothing at all until the round-trip returns, and if the reload then misbehaves there is no
intermediate state to fall back on.

Invert it:

1. On drop — remove the item from the current list immediately (or grey it out as in-flight).
2. On success — refresh; the optimistic state was already right, so nothing visibly moves.
3. On failure — restore it and surface the error.

This is the optimistic-update pattern from #4, applied to just the item list. Worth doing here
first: it is a small, self-contained change, and it fixes the symptom regardless of which of the
two causes above turns out to be the real one — which is a good property, because the cause is
still unconfirmed.

Two implementation notes

Grey out rather than remove. Removing and then restoring on failure makes the row disappear and
reappear somewhere else in a sorted list, which reads as a glitch. Dimming it and disabling
interaction shows the same intent, makes the in-flight state legible, and turns rollback into
simply un-dimming. Removal is the right end state once the write is confirmed.

The success path still needs #2. Even with an optimistic update, step 2's refresh currently
rebuilds the whole tree and discards expansion state. So this fix makes the list correct but the
tree will still reset until #2 is done — or until the refresh becomes an in-place reconciliation,
which would settle both.

Scope note carried over from #4: optimism is for moves — one reversible field on one item.
It must not reach the merge path, which writes, verifies, and only then deletes.