My use case which is driving the fix for this bug is user expectation in an
open source application (https://github.com/ccavanaugh/jgnash).
When a user makes an edit to an existing transaction, the expectation is
the prior selected ComboBox value is visible when the list is displayed,
otherwise it gives the impression they made an error or something is
wrong. I think the root cause of the poor experience is seeing the correct
value when collapsed, and then not seeing it or it's selection when
expanded.
Also, scrolling automatically was the default behavior for Swing.
My current work around is an extended ComboBox that listens for a mouse
click or key events and then scrolls the list view.
On Fri, Apr 3, 2020 at 8:19 AM Jeanette Winzenburg <
faste...@openjdk.java.net> wrote:
> On Fri, 3 Apr 2020 12:03:33 GMT, Jeanette Winzenburg <faste...@openjdk.org>
> wrote:
>
> >>> Can you please provide a unit test? One that fails before your fix and
> passes after your fix.
> >>
> >> I can provide a manual test the next couple of days that demonstrates
> it before and after, but I'm not sure how to
> >> create an automated unit test because the issue is visual.
> >
> > A quick snippet of how-to write a unit test (for setup see other tests
> in controls) that will fail before and pass
> > after the change:
> > @Test
> > public void testScrollInSkin() {
> > int index = 50;
> > comboBox.getSelectionModel().select(index);
> > comboBox.show();
> > VirtualFlow<IndexedCell<?>> virtualFlow = getFlow();
> > int first = virtualFlow.getFirstVisibleCell().getIndex();
> > int last = virtualFlow.getLastVisibleCell().getIndex();
> > assertTrue(" visible range [" + first + ", " + last + "] must
> include " + index,
> > first <= index && index <= last);
> > }
> >
> > protected VirtualFlow<IndexedCell<?>> getFlow() {
> > VirtualFlow<IndexedCell<?>> virtualFlow =
> (VirtualFlow<IndexedCell<?>>)
> > VirtualFlowTestUtils.getVirtualFlow(comboBox);
> > return virtualFlow;
> > }
>
> A couple of comments to the bug (and fix) itself:
>
> - is it really a bug or a nice-to-have enhancement? couldn't find an
> example in win, didn't try too hard and nowadays,
> such plain combos are not a really frequent
> - while none of the virtualized controls (nor ChoiceBox) combines
> selection with scrolling to the selected item. For
> combo and choice, I see no reason not make it the default behavior. We
> need to make certain it behaves "naturally" when
> navigating in the open popup. instead of catching every list.select (and
> not forget the unselect) we might consider
> doing it in a showing handler alternatively, we might consider to go
> deeper and support it directly in the listView
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/136
>
