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

[Kevin Rushforth]

This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level touch 
events disabled, I can use the trackpad to rotate and zoom and the app 
picks it up fine.

Mouse events, including trackpad scrolling events, are not affected at 
all by this.

-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
> 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
>>
>