The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To reproduce:
1. Cilck button "Initialize";
2. Move mouse over the tree table and turn the wheel.
=>There will be no effect. Output is expected to appear when onScroll is fired.
Comments
In this case the onScroll's documentation should be rewritten completely (with clear explanation where is the place of onScroll in the event dispatch chain)
08-09-2016
I filed JDK-8165695 to improve the docs.
08-09-2016
No, the documentation should not be rewritten completely.
An Event already has the property of being "consumed" which stops further propagation. We could add a clarifying paragraph to the Control class docs indicating that most controls will consume various input events, and to the Node class definition indicating that if an event gets consumed by someone else it will not be delivered, but we do not want to tightly specify this. Given that JavaFX has worked this way since FX 2 this is not a high priority task, and is unlikely to happen for JDK 9.
08-09-2016
This would be a behavior change and not something we plan to do. Nor is there a good reason from an application point of view. As with recently closed bug JDK-8163268, there is no expectation that these events are available and propagated to an application listening for them.
07-09-2016
onScroll is a public interface. According to documentation it "defines a function to be called when user performs a scrolling action". It seems that the current behavior is rather related with consuming events by the control's skin and not actually intended. Is there a serious problem to implement it as described in the documentation?
07-09-2016
ScrollEvents are fired and printed in the console in situations where the control can't scroll, but in instances where it can, these events are consumed and not propagated further.