RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v3]

[Ambarish Rapte]

On Mon, 26 Apr 2021 18:58:02 GMT, mstr2 <github.com+43553916+mstr2 at 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