Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Michael Paus]

Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are
working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:
> To: Mac app developers / users
>
> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
> Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
> effect of this bug is that a scary dialog is shown for all users the 
> first time they run a JavaFX application and move the mouse is moved 
> into the JavaFX window. It also is reported to block apps from being 
> accepted in the Apple store.
>
> This bug is caused by a change in macOS 10.15 to require additional 
> permissions for using CGEventTap, which JavaFX uses to track touch 
> events.
>
> The suggested replacement API, 
> NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
> enough (it tracks events delivered to a specific view, whereas the 
> current code is implemented using a global monitor and a global set of 
> touch points), that it would be too risky to change it this late in 
> the release.
>
> Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
> wanted to get some input from Mac users on the list. I can think of 
> the following possibilities for JavaFX 14:
>
> 1. Do nothing (defer the bug to FX 15)
> 2. Disable touch events completely if running on macOS 10.15 (or 
> later) -- we could consider a system property to re-enable it, but I 
> don't really like that idea, and I'm not sure how useful it would be 
> anyway since setting that flag would cause the scary dialog again.
> 3. Defer enabling of touch events until the first time the application 
> requests them -- this would require new interfaces in Glass, isn't 
> risk free, and doesn't solve the dialog problem for those apps that do 
> use touch.
>
> I'm leaning towards option #2 (without the system property to force 
> enable it), but wanted to get a sense from app developers as to 
> whether that would be more of a problem than doing nothing (i.e., 
> option #1). I only listed option #3 for completeness, since it doesn't 
> really solve the issue.
>
> Whatever we do for 14, the solution for 15 will very likely be to 
> switch to tracking per-View (per Window) touch events, either 
> directly, or maybe using local event monitoring.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231513
>