On Mon, 26 Apr 2021 18:58:02 GMT, mstr2 <github.com+43553916+ms...@openjdk.org>
wrote:
>> The documentation for `ObservableListBase.nextRemove` states that a single
>> change always refers to the current state of the list, which likely means
>> that multiple disjoint removed ranges need to be applied in order, otherwise
>> the next change's `getFrom` doesn't refer to the correct index.
>>
>> `SelectedItemsReadOnlyObservableList` doesn't apply removals to
>> `itemsRefList`, which means that subsequent removals will refer to the wrong
>> index when retrieving the removed elements. This PR fixes the calculation of
>> the current index.
>
> mstr2 has updated the pull request incrementally with two additional commits
> since the last revision:
>
> - Cleanup
> - Added tests
The fix solves the problem that is described in the bug.
But the similar problem can be observed with different number of items and
different selection.
In the test program attached to the bug, make following one line change to add
two more items "three" and "four"
`final ObservableList<String> listitems =
FXCollections.observableArrayList("zero", "one", "two", "three", "four");`
Scenarios where the issue still occurs:
Scenario 1:
1. Click on item `one`
2. Press ctrl key and select items `two` and `three`
2. Click on item `two` or on item `one`
3. => Observe that output is incorrect
4. => Similar issue can be observed with items `two`, `three` and `four`
5. => But this does not occur with one, `two` and `three`
Scenario 2:
1. Click on item `two`
2. Press ctrl key and select items `three`, `four` and `one` in this order
2. Click on item `two` or on item `one`
3. => Observe that output is incorrect
It looks like getRemoved() is not correct in all cases when first item `zero`
is no involved
-------------
PR: https://git.openjdk.java.net/jfx/pull/478
