On Fri, 1 May 2020 14:46:21 GMT, Kevin Rushforth <k...@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
