Given a TableView with multiple and cell selection modes enabled like the attached test, select one cell via mouse click, and then use Shift+arrow keys to select a group of cells over a continuous path, including two or more rows or two or more columns (see for instance Initial selection.png).

Then start deselecting those cells with Shift+arrow keys, in the reverse order of selection.

The last cell selected is now deselected and the focused cell remains selected (as expected, see First deselection.png).

But deselecting one more cell doesn't work: the cell remains selected and the focused one gets deselected, which is not expected, see Second deselection.png.

This issue is related to the "backtracking" algorithm used in TableViewBehaviorBase::updateCellVerticalSelection (see https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java#L714), which makes use of a selection history linked list.

Selected cells are added to the beginning of the list, so when going the selection path backwards, the first deselection finds the focused cell at index 1 (as expected), but, since no cells are removed from such list, the second deselection still picks that same index 1.

On the other hand, TableViewBehaviorBase::updateCellHorizontalSelection doesn't use the selection history list, but the selected cells list (which is always ordered from left to right, top to bottom), so in case the selection goes from right to left and deselection goes from left to right, the same issue could happen, and the wrong cell is selected/deselected.

This issue can be reproduced with any JavaFX version and platform.

Additional notes from JDK-8297167 (which is marked as duplicate of this ticket):

To reproduce, click on the top left cell (R0:C0), then press shift-right arrow 4 times, followed by shift-down arrow key 4 times, followed by shift-up arrow 4 times, followed by shift-left arrow 4 times. The expectation is that we should have no cells selected. Instead, there is a weird pattern of selected cells (see the screenshot).

There are probably other similar scenarios using different paths.

There is a unit test which is currently @ Ignored in TableViewKeyInputTest.testSelectionPathDeviationWorks1() - I think there might be problems with that test because the comments describing what's supposed to happen do not correspond to the code.