JDK-8236971 : [macos] Gestures handled incorrectly due to missing events
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: openjfx14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2020-01-11
  • Updated: 2020-06-09
  • Resolved: 2020-04-06
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 download the current JDK release, click here.
JDK 8 Other
8u251Fixed openjfx11.0.8Fixed
Related Reports
Relates :  
Relates :  
Description
On my MacBook Pro I can observe the following incorrect behavior for gestures. See attached demo program. (I can't say what the behavior
on other platforms is.)

When I move two fingers over the built-in track pad, I get the following kind of output:

setOnScroll: 0,000000 0,000000 1,000000 1,000000 0
setOnScroll: 0,000000 0,000000 2,000000 2,000000 0
setOnScroll: 0,000000 0,000000 1,000000 1,000000 0
setOnScroll: 0,000000 0,000000 1,000000 1,000000 0
setOnScroll: 1,000000 1,000000 1,000000 1,000000 0
setOnScroll: 1,000000 1,000000 2,000000 2,000000 0
setOnScroll: 1,000000 1,000000 1,000000 1,000000 0
setOnScroll: 1,000000 1,000000 1,000000 1,000000 0

The values are: e.getDeltaX(), e.getTotalDeltaX(), e.getDeltaY(), e.getTotalDeltaY(), e.getTouchCount()

This is wrong for several reasons according to the documentation for ScrollEvent:

1. The sequence of events for one gesture is never surrounded by SCROLL_STARTED and SCROLL_FINISHED.
2. The total-delta values are never accumulated. They seem to be the same as the delta values.
3. The touch-count is always 0. I'd expected 2 in this case.

This is also inconsistent with zoom events, where I get at least sometimes a zoom-started or zoom-finished notification. But this behavior is also not correct because it seems the zoom events are not surrounded correctly. Often I just get something like this:

setOnZoom: 0,998001
setOnZoom: 0,998001
setOnZoom: 0,994003
setOnZoomFinished
setOnZoomStarted

For rotation events the accumulation behavior actually works in contrast to the scroll events.

When I now attach an USB mouse to my Mac and create scroll events with the mouse wheel, the behavior is also wrong. The documentation says: "The totalDeltaX and totalDeltaY contain the cumulative values for the whole gesture, zeros for mouse wheel". As you can see here, the total-deltas for y are not zeros.

setOnScroll: 0,000000 0,000000 1,000061 1,000061 0
setOnScroll: 0,000000 0,000000 1,000061 1,000061 0
setOnScroll: 0,000000 0,000000 1,000061 1,000061 0
setOnScroll: 0,000000 0,000000 1,000061 1,000061 0
setOnScroll: 0,000000 0,000000 4,296417 4,296417 0
setOnScroll: 0,000000 0,000000 -1,000061 -1,000061 0
setOnScroll: 0,000000 0,000000 -11,195526 -11,195526 0
setOnScroll: 0,000000 0,000000 -38,627014 -38,627014 0
setOnScroll: 0,000000 0,000000 -50,805664 -50,805664 0
setOnScroll: 0,000000 0,000000 -52,142639 -52,142639 0

The current behavior is especially problematic for me because there does not seem to be any reliable way now to distinguish between mouse and track pad generated scrolling for which I have to take differnt actions.
Comments
Changeset: 247a65d2 Author: Kevin Rushforth <kcr@openjdk.org> Date: 2020-04-06 15:10:58 +0000 URL: https://git.openjdk.java.net/jfx/commit/247a65d2
06-04-2020

As discussed in the PR for this bug, https://github.com/openjdk/jfx/pull/156, we will use this bug for the mac-specific bug preventing begin/end gestures from being sent properly when running on a JDK compiled and linked against a newer MacOSX SDK. The issue of the deltas being wrong for mouse-wheel events will be tracked in a follow-on bug, JDK-8242122.
03-04-2020

This bug is a result of a deliberate change by Apple that affects applications linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, beginGestureWithEvent and endGestureWithEvent. There is no deprecation warning or any other indication at compile time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer guide: https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc I note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK or later. The solution, as indicated in the Apple documentation, is to use the phase information from gesture events to track when to call begin / end gesture.
02-04-2020

This may have been caused (or triggered) as a result of using a newer Xcode / MacOSX SDK to build the JDK. I'll take a look at this for JavaFX 15, in case we can work around the problem. Otherwise we might need a fix in the JDK.
31-03-2020

I can now confirm that at least the mouse wheel behaviour is also wrong on Windows 10. So this is not just a Mac issue. I did this test with the latest OpenJFX 15-ea+2. I don't have a touch device for Windows, so I can't test that.
05-03-2020

I am running on macOS 10.14.6.
18-01-2020

What version of macOS are you running?
18-01-2020

Further investigations reveal that this actually seems to be a regression in the JDK and not in JavaFX. The following combinations of JDK/JFX have been examined. Oracle 8 with JavaFX contained works and OpenJDK 11 combined with JFX 14 also works. It starts to fail with OpenJDK 12. Interestingly GraalVM 11 combined with JFX 14 also fails. The following combinations work correctly with the exception that total deltas are not set to zero for mouse wheel. java.runtime.version: 1.8.0_221-b11 javafx.runtime.version: 8.0.221-b09 setOnScrollStarted setOnScroll: 10,000000 18,000031 0,000000 -6,000061 0 setOnScroll: 0,000000 18,000031 -7,000122 -13,000183 0 setOnScroll: 12,000122 30,000153 0,000000 -13,000183 0 setOnScroll: 0,000000 30,000153 -9,000092 -22,000275 0 setOnScroll: 10,000000 40,000153 0,000000 -22,000275 0 setOnScroll: 0,000000 40,000153 -9,000092 -31,000366 0 setOnScroll: 11,000061 51,000214 0,000000 -31,000366 0 setOnScroll: 11,000061 62,000275 -8,000031 -39,000397 0 setOnScroll: 9,000092 71,000366 -8,000031 -47,000427 0 setOnScrollFinished java.runtime.version: 11.0.5+10 javafx.runtime.version: 14-ea+7 setOnScrollStarted setOnScroll: 1,000000 2,000000 -2,000000 -3,000000 0 setOnScroll: 2,000000 4,000000 -2,000000 -5,000000 0 setOnScroll: 1,000000 5,000000 -1,000000 -6,000000 0 setOnScroll: 1,000000 6,000000 -2,000000 -8,000000 0 setOnScroll: 1,000000 7,000000 -2,000000 -10,000000 0 setOnScroll: 1,000000 8,000000 -1,000000 -11,000000 0 setOnScroll: 1,000000 9,000000 -1,000000 -12,000000 0 setOnScroll: 1,000000 10,000000 -1,000000 -13,000000 0 setOnScroll: 1,000000 11,000000 -1,000000 -14,000000 0 setOnScroll: 1,000000 12,000000 -1,000000 -15,000000 0 setOnScroll: 1,000000 13,000000 -1,000000 -16,000000 0 setOnScroll: 1,000000 14,000000 -1,000000 -17,000000 0 setOnScrollFinished It starts to fail as described with JDK 12 and above. java.runtime.version: 12.0.2+10 javafx.runtime.version: 14-ea+7 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 1,000000 1,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -3,000000 -3,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -3,000000 -3,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 2,000000 2,000000 -2,000000 -2,000000 0 setOnScroll: 1,000000 1,000000 -2,000000 -2,000000 0 setOnScroll: 1,000000 1,000000 -2,000000 -2,000000 0 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 0,000000 0,000000 0 setOnScroll: 1,000000 1,000000 -1,000000 -1,000000 0 setOnScroll: 1,000000 1,000000 0,000000 0,000000 0
12-01-2020

This sounds like either a bug in the window-toolkit (glass) or in the event handling code (scenegraph).
11-01-2020