Gracefully handle the deletion of an edited table cell #7552
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
User-facing changes: deleting a row with a currently-edited table cell no longers throws an exception.
Technical notes: JavaFX strikes again... This looks like a helpful behavior they introduced in some update — committing a change of a cell that loses focus. Unfortunately, it happens to be executed in the order we didn't anticipate. The user clicks the "Remove" button -> we execute the
:remove-table-selection
handler -> we now get new items -> we set new items on a table view -> table view notices that we edit the table and commits the edit before replacing the cell -> we execute the:commit-table-edit
handler on a new items vector, but the edit is applied as if to the old items vector. I.e. we track an index to change while editing, and it corresponds to the old vector. So, if we remove the last item that was edited, the index will be out of bounds by one. Applying the edit is(assoc items index new-value)
, which will act asconj
in case of off-by-oneassoc
. Just canceling the edit will prevent JavaFX from committing it which is a way out of this mess.Fixes #6924