Bug ID: JDK-8284665 First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
openjfx19Fixed

On a TreeTableView that gets new TreeItems added continuously, at some fast rate, with multiple selection enabled, after selecting an item and then pressing shift to extend the range to a group of items, the selection removes the first item, which is unexpected.

When no more items are added to the TreeTableView or these are added at a low rate (several seconds), then the selection works as expected, if it happens after some time of the last addition.

This issue can be reproduced with any JavaFX version.

To reproduce, run the attached test.

- Select Node 1 (see selectNode1.png) 
- Press Shift to extend the range to items Node 1, 2, 3 and 4. Note the selection removes the first item and only three items are selected (see shiftSelectNode4Fails.png)

Wait around 10 seconds (until 100 treeItems have been added), do it again:

- Select Node 1 (see selectNode1.png) 
- Press Shift to extend the range to items Node 1, 2, 3 and 4. Note the selection works as expected and four items are selected (see shiftSelectNode4Works.png).

A pull request was submitted for review. URL: https://git.openjdk.java.net/jfx/pull/790 Date: 2022-05-05 16:21:45 +0000
05-05-2022
It seems this issue was introduced with JDK-8095881, which was applied not only to TreeTableView, but also ListView, TableView and TreeView. I can reproduce the issue based on a similar test with a TableView, but not with a ListView or a TreeView. The fix is the same for the two controls, so I guess it could be done from this single JBS issue?
05-05-2022
It's not that only one item gets removed from the selection. It may remove multiple items when selecting using Shift + Down arrow key. In addition, If we select items using Shift + UP arrow key, then and extra item on bottom side of selection gets added into the selection.
13-04-2022
Adding a listener: table.getSelectionModel().getSelectedItems().addListener((ListChangeListener<TreeItem<String>>) change -> System.out.println("change = " + change)); and performing the mentioned steps, shows: - if items are being added: change = { [TreeItem [ value: Node 1 ]] added at 0 } change = { [TreeItem [ value: Node 1 ]] removed at 0 } change = { [TreeItem [ value: Node 2 ], TreeItem [ value: Node 3 ], TreeItem [ value: Node 4 ]] added at 0 } - if items are not being added anymore: change = { [TreeItem [ value: Node 1 ]] added at 0 } change = { [TreeItem [ value: Node 1 ]] removed at 0 } change = { [TreeItem [ value: Node 1 ], TreeItem [ value: Node 2 ], TreeItem [ value: Node 3 ], TreeItem [ value: Node 4 ]] added at 0 } TableCellBehaviourBase::doSelect has: final TablePositionBase anchor = getAnchor(tableView, focusedCell); when Node 1 is selected, focusedCell is row 1 (as expected), anchor returns row 1 (as expected) when the treeTableView size doesn't change. However, anchor returns row 2 (unexepected) when items are being added. That leads to the treeItemListener in TreeTableView, that has a shift=addedSize when e.wasAdded that calls: TreeTablePosition<S, ?> newAnchor = new TreeTablePosition<>(treeTableView, anchor.getRow() + shift, anchor.getTableColumn()); TreeTableCellBehavior.setAnchor(treeTableView, newAnchor, false); if the anchor was part of the selection. For the current test, this shifts unexpectedly the anchor of a row that is part of the selection but is not part of the change, which happens several rows below. This should only happen if the anchor was _after_ the startRow of the change.
11-04-2022