On Mon, 8 Mar 2021 23:47:32 GMT, Kevin Rushforth <k...@openjdk.org> wrote:

>> This PR changes the parameter names to accommodate class calculations 
>> related to screen event coordinates (AbsX, AbsY).
>> 
>> As 
>> [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707),
>>  the sendScrollXXXEvent methods are currently passing the screen coordinates 
>> (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the 
>> screen ones.
>> 
>> Tested successfully on Android with ComboBox controls in different positions.
>
> Since this touches shared code, what testing have you done to ensure that it 
> works as expected on other platforms?

I've tested Mac (via touchPad), but even setting 
`com.sun.javafx.gestures.scroll` to true, `ScrollGestureRecognizer` doesn't get 
called (via `GlassViewEventHandler::handleEndTouchEvent`), as the flow of 
scroll events goes through `GlassViewEventHandler::handleScrollGestureEvent`.

Same on Linux and Windows (via touchPad), where the flow of scroll events goes 
through `GlassViewEventHandler::handleScrollEvent`.

I've also tested on Windows with a touch enabled display (and 
`com.sun.javafx.gestures.scroll` set to true). 
In this case, scroll events are handled mostly via 
`GlassViewEventHandler::handleScrollGestureEvent`, but also by 
`ScrollGestureRecognizer`. Before this PR, the latter added wrong coordinates 
to the gesture, causing the scroll to stop. With the changes, there are a few 
events, but they are now exactly the same as those from 
handleScrollGestureEvent (so there are duplicated calls to 
`scene.sceneListener.scrollEvent`), and the scroll is more fluid, doesn't stop. 
(Anyway, I don't think it is expected to set `com.sun.javafx.gestures.scroll` 
in this platform)

-------------

PR: https://git.openjdk.java.net/jfx/pull/420

Reply via email to