You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(linux): clear selection after Delete + correct row lookup with drafts
User-reported: Ctrl+A → Delete leaves the "{n} selected" badge stuck
because the rows stay in the model (strikethrough until Save), so the
MultiSelection bitset is unchanged and connect_selection_changed never
fires. Now the bulk-delete commit closure calls
selection.unselect_all() at the end of both branches (immediate +
post-confirm), which propagates through the existing chrome-update
signal: badge hides, Delete tooltip resets to single-row.
Deeper bug uncovered while tracing: row_position arrives in
filter-model space (the space GtkColumnView activates against) which
includes prepended drafts, but DeleteSelectedRow's snapshot loop and
row_key_at both indexed result.rows directly. With N drafts visible at
the top of the grid, every "delete row at position P" or "edit cell at
position P" silently targeted the wrong persisted row's PK (off by N).
Both call sites now resolve through selection.model().item(pos), pull
cells via row_object.cells_clone(), and skip rows whose draft_id() is
Some — drafts have no PK and need a different teardown path anyway.
Affects: right-click context-menu Delete, Ctrl+Shift+N Set NULL, and
any cell edit on a persisted row that sits below a draft. Latent until
the user inserted a draft + acted on a persisted row in the same
session.
0 commit comments