8328167: ScrollTo in ListView still doesn't work since VirtualFlow was modified

[winrid]

Should fix: https://bugs.openjdk.org/browse/JDK-8328167?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

I have an application with a TableView that adds items and scrolls to them, and it's very important the last added item is visible to the user. When the first item is added that triggers the scroll, and you do a platform.runLater -> scrollTo(lastNewItem) the scrollTo does not work.

I think this is because of something to do with rendering phases, as two nested runLaters do work it seems, but that's pretty naughty.

I tried adding a test for this but I think the way the javafx tests runs differ a bit from an actual app? I am happy to add a test maybe with a recommendation on the approach. I have a reproducer with documentation here: https://github.com/winrid/jfx-jdc-8328167-scrollto-reproducer

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Error

 ⚠️ OCA signatory status must be verified

Issue

• JDK-8328167: ScrollTo in ListView still doesn't work since VirtualFlow was modified (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/2041/head:pull/2041
$ git checkout pull/2041

Update a local copy of the PR:
$ git checkout pull/2041
$ git pull https://git.openjdk.org/jfx.git pull/2041/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2041

View PR using the GUI difftool:
$ git pr show -t 2041

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/2041.diff

[bridgekeeper]

Hi @winrid, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user winrid" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[winrid]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[winrid]

I would like to note that I signed the OCA, but I followed the guide in the repo before creating the PR, and that guide does not say to Please fill in your GitHub username in the "Username" field of the application., so I didn't. I guess that means it won't automatically work.

[johanvos]

Hi @winrid
I didn't look into the details yet, but in any case it is really important to have a regression test for this.
A large number of issues in VirtualFlow are caused by changes that fix other issues. They often cause undetected regression, because we don't have enough tests. The VirtualFlow area is used in many different circumstances, where there are often implicit assumptions about how it should behave that are contradicting other assumptions in other circumstances.
Hence, in order to prevent going back and forth, we need regression tests for every change we do, so that future PR's can't undo what is done in this PR.

[winrid]

@johanvos For sure, would simply asserting via a stub that scrollTo is called when expected be enough? That should catch most regressions. I tried adding a test that actually checks if the element is visible, but it only worked outside of the test harness.