RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list

[Ambarish Rapte]

On Fri, 1 May 2020 14:46:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue:
>> When tabs are permuted as mentioned in the issue description as,
>> 1. TabPane.getTabs().setAll(tab0, tab1)
>> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
>> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>> 
>> => tab headers should be shown in order as  tab0, tab1, tab2, tab3.
>> => but are show in order as  tab2, tab3, tab0, tab1
>> 
>> Cause:
>> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does
>> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list.
>> Fix:
>> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable.
>> 
>> Verification:
>> No existing tests fail due to this change.
>> Added a system test which fails without and pass with fix.
>
> tests/system/src/test/java/test/robot/javafx/scene/TabPanePermuteGetTabsTest.java line 224:
> 
>> 223:         });
>> 224:         delay();
>> 225:
> 
> Does using Robot to select the Tab test add value? Probably not worth worrying about given that this will all move to
> the controls unit tests with [JDK-8244195](https://bugs.openjdk.java.net/browse/JDK-8244195).

In these scenarios, the `TabPane.getTabs()` has correct sequence. So selecting a tab using `TabPaneSelectionModel` does
not test the issue. Using Mouse guarantees that `TabHeaderArea` has correct order of tabs. But anyway once we convert
these tests to unit tests, mouse events will be removed.

-------------

PR: https://git.openjdk.java.net/jfx/pull/201