RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set
fastegal at openjdk.java.net
Sun Apr 26 10:44:26 UTC 2020
On Sun, 19 Apr 2020 10:37:56 GMT, Craig Cavanaugh <github.com+636962+ccavanaugh at openjdk.org> wrote:
> For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the
> illusion of a preselected value not actually being selected because it's not visible if the list is large and has been
> shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort
> and time.
Yes, I understand the perspective of the users (would be unhappy with it as well) - but from the perspective of the fx,
it's the job of the application developer to keep a selected item visible. Which s/he could do easily enough, even for
a comboBox. Also I agree, that in the case of the combo it feels unexpected to not the selected item on opening the
popup. So we could do something about it - but we have to specify _exactly_ what that something should be.
> With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with
> it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires
> scrolling, so the selected value is already visible.
Hmm, probably wasn't clear enough: have a combo with many items, open the popup, navigate (via keys like page/up/down
..) and compare the behavior before/after the fix. I see considerable differences in behavior. F.i. keyDown does move
the selection one-down without scrolling before and scrolls down by one after (making the selected item visually
"stick" at the top). Do you see that as well or did I goof somehow (also a possibility :) ?
Navigation behavior should be the same before/after, I think. There might be other behavior changes introduced (didn't
check further, it's your issue :), that we should actively look out for.
> I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the
> value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being
> performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process
> to select the final value.
not sure what you mean by "one shot process" and "final value": the fix scrolls the list to top whenever the value
changes, and the value is changed whenever the selectedItem is changed which happens on navigation (that is user
interaction) as well as changing it programatically.
Maybe we should really go back to square one and _exactly_ specify when we want the value be scrolled into view. The
current fix does so for _each_ selection (which has rather broad effects). If it could be bounded a bit more, the
effects would be narrower. That's why I suggested to limit it f.i. to the time of opening the popup (which is rather
rare compared to selection change).
> Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying
yeah, forget about ChoiceBox, I was wrong <g>- whoever needs to scroll to the selected value is using the wrong control
> My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not
> collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience?
Ahh, guilty of having been unclear again, sry - what I meant is to add support of doing a well-behaved scrolling in
ListView (and the other virtualized controls): scrollTo is not overly well-behaved. And I agree, doing it always and
unconditionally, might introduce a bad user experience.
More information about the openjfx-dev