On Mon, 18 May 2026 20:15:40 GMT, Martin Fox <[email protected]> wrote:
> On macOS when the user swipes on a trackpad or Magic Mouse JavaFX sees this > as a scroll gesture. The scene tries to ensure that all the scroll events > generated by the gesture are fired at the same target to ensure that the > gesture's scroll events don't get split between two ScrollPanes. For example, > while a ScrollPane is being scrolled a child ScrollPane might shift until > it's beneath the mouse pointer. Scroll events should not fire at the child > but remain with the parent. > > During the gesture the scene should target the node that's handling the > scrolling (like a ScrollPane) but there's no good way to determine that. > Instead it targets a descendant node, whatever was under the mouse pointer > when the gesture started. This node is likely to shift during the scroll and > if scrolls out of view it might get disconnected from the scene graph. At > that point events fired at it will go nowhere and the gesture will abruptly > stop. > > This PR detects when the gesture target is removed from the scene graph and > attempts to find a new target. > > This bug does not reproduce on Windows since that platform doesn't generate a > SCROLL_STARTED event so the Scene never selects a gesture target. All scroll > events are delivered to whatever node is under the mouse pointer which will > change as the scroll progresses. > > This PR might fix [JDK-8088460](https://bugs.openjdk.org/browse/JDK-8088460) > which shows up in Ensemble if anyone wants to test that. > > Submitting fix for sanity checking and manual testing. Will investigate > creating an automated test for this. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). While reading the patch, I wondered about one small consistency edge case: in the retargeting branch, if the previous gesture target has been detached and the current pick has no intersected node, `pickedTarget` stays `null`. The existing non-cached path falls back to the `Scene` in that case. Would it be worth keeping the same fallback behavior here? A related minor thought: would `pickedNode.getScene() != this` be a slightly broader check than `pickedNode.getScene() == null`? It would cover both a detached node and the unlikely case where the old target has been moved to another scene before the rest of the gesture is delivered. This does not change the main idea of the fix; I am only asking whether this branch should mirror the existing dispatch path more closely. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2171#issuecomment-4561992191
