8279228 Leak in ScrollPaneSkin, related to touch events

[FlorianKirmaier]

Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running,
and the node is removed from the Scene, then the animation will never stop, causing a memory leak.
A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8279228: Leak in ScrollPaneSkin, related to touch events

Reviewers

• Ajit Ghaisas (@aghaisas - Reviewer)
• Kevin Rushforth (@kevinrushforth - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/701/head:pull/701
$ git checkout pull/701

Update a local copy of the PR:
$ git checkout pull/701
$ git pull https://git.openjdk.java.net/jfx pull/701/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 701

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/701.diff

[bridgekeeper]

👋 Welcome back fkirmaier! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 00: Full (b9a6594c)

[kevinrushforth]

Two quick questions:

1. The fix checks whether or not the node is treeShowing at the time the startSBReleasedAnimation method is called. Is this sufficient? If a node's tree showing state changes, is it guaranteed that this method will be called?
2. Can you provide an automated test for this?

/reviewers 2

[openjdk]

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

[FlorianKirmaier]

1.)
It's not only called at the beginning of the startSBReleasedAnimation, but whenever the animation is repeated, which is the cause for the leak. It happens when touchDetected == true || mouseDown == true is true. The animation is then basically restarted every frame. With my change, it also checks whether the node is still visible, which fixes the problem.

2.)
It's probably possible if there is a way to simulate Touch Events. The Robot doesn't seem to support it. A test would also require a way to set the "IS_TOUCH_SUPPORTED" property.
Honestly, I don't think it's a good time investment, because the fix is quite simple. I don't even know exactly when it happens - I've just made sure it no longer loops the animation when the ScrollPane is no longer visible.

I've also applied the fix in an affected application, and it clearly fixes the problem.

[aghaisas]

This simple fix looks good to me.

[openjdk]

@FlorianKirmaier This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8279228: Leak in ScrollPaneSkin, related to touch events

Reviewed-by: aghaisas, kcr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 44 new commits pushed to the master branch:

• 6f201f7: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
• a0bb545: 8281953: NullPointer in InputMethod components in JFXPanel
• 7396396: 8282134: Certain regex can cause a JS trap in WebView
• 418d343: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
• 2561e31: Merge
• 8b879ee: 8271085: TabPane: Redundant API docs
• ed39982: 8279345: Realign class docs of LightBase and subclasses
• 6b7b463: 8280841: Update SQLite to 3.37.2
• cdebc6c: 8281459: WebKit 613.1 build broken on M1
• 4cf66d9: 8187309: TreeCell must not change tree's data
• ... and 34 more: https://git.openjdk.java.net/jfx/compare/c705bd493931d88650542be5466d6add359f45b9...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@aghaisas, @kevinrushforth) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[FlorianKirmaier]

/integrate

[openjdk]

@FlorianKirmaier
Your change (at version b9a6594) is now ready to be sponsored by a Committer.

[kevinrushforth]

/sponsor

[openjdk]

Going to push as commit adf1da4.
Since your change was applied there have been 44 commits pushed to the master branch:

• 6f201f7: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
• a0bb545: 8281953: NullPointer in InputMethod components in JFXPanel
• 7396396: 8282134: Certain regex can cause a JS trap in WebView
• 418d343: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
• 2561e31: Merge
• 8b879ee: 8271085: TabPane: Redundant API docs
• ed39982: 8279345: Realign class docs of LightBase and subclasses
• 6b7b463: 8280841: Update SQLite to 3.37.2
• cdebc6c: 8281459: WebKit 613.1 build broken on M1
• 4cf66d9: 8187309: TreeCell must not change tree's data
• ... and 34 more: https://git.openjdk.java.net/jfx/compare/c705bd493931d88650542be5466d6add359f45b9...master

Your commit was automatically rebased without conflicts.

[openjdk]

@kevinrushforth @FlorianKirmaier Pushed as commit adf1da4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.