New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set #166
Conversation
|
was: #136 |
I am taking a look at your changes now. |
Thank you. I've updated the pull request comments with what I thought was
the necessary changes, but jcheck is still failing with
"the commits in this PR have inconsistent user names and/or email
addresses. Please amend the commits."
I'm not sure what to do with this error.
Thanks,
Craig
…On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas ***@***.***> wrote:
I am taking a look at your changes now.
@ccavanaugh <https://github.com/ccavanaugh> can you make jcheck pass
while I review. Please see the details of the failing jcheck.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#166 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3QISJFVRRHVFI3XXI6U3RMQRLRANCNFSM4MES2KIA>
.
|
I think you will need to rebase and force push your branch. |
Seems I've made a further mess attempting to rebase. I apologize as I know
the list is not intended to be tech support for git usage, but I'm at a
loss and don't want to make it worse.
Below is the log after an interactive rebase and forced push.
""
Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123
branches 8129123, origin/8129123
""
Thanks,
Craig
…On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth ***@***.***> wrote:
I think you will need to rebase and force push your branch.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#166 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3QIRVUG2DTSQ7H7BFJT3RMRAGBANCNFSM4MES2KIA>
.
|
The following should work:
If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the following:
|
/reviewers 2 |
@kevinrushforth |
https://bugs.openjdk.java.net/browse/JDK-8129123 Unit test for JDK_8129123
That did it!
Thanks!
…On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth ***@***.***> wrote:
The following should work:
$ git rebase -i master
If the rebase is successful, it will pop you into your EDITOR. You then
select "pick" for the first commit (which is already selected by default)
and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good
to you, do the following:
$ git push --force origin 8129123
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#166 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3QIRSLJFPKYG2F7B4VO3RM326XANCNFSM4MES2KIA>
.
|
Webrevs
|
I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired result for ComboBox. It is nice to have behavior and I am OK with the fix.
Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. I have a minor comment regarding test. |
int last = virtualFlow.getLastVisibleCell().getIndex(); | ||
assertTrue(" visible range [" + first + ", " + last + "] must include " + index, | ||
first <= index && index <= last); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have tested first and last index selection.
It will be nice to have a case where we select index = LIST_SIZE/2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, mid point test added
repeating my comment from the previous pull request: I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered :) |
/reviewers 2 |
@kevinrushforth |
This will need two reviewers. As part of this review, the questions raised by @kleopatra in this message from the original PR need to be answered. |
|
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.
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.
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).
yeah, forget about ChoiceBox, I was wrong - whoever needs to scroll to the selected value is using the wrong control ..
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. |
I meant to close this PR out a while ago, but it kept getting put on the back burner. I don't think this PR is the right approach to the problem. I can confirm that this doesn't behave naturally at all when using the arrow or page up / page down keys when the combo is open. Before we make any changes in FX itself we need to specify what the behavior should be for various cases, including multiple selections, scrolling while the combo is open, changing the selection while the combo is open, etc. |
https://bugs.openjdk.java.net/browse/JDK-8129123
This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms.
Also, I believe JDK-8196037 is a duplicate of this issue.
I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10.
Thanks!
Progress
Issue
Download
$ git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166
$ git checkout pull/166