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

[Michael Paus]

In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't miss 
them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that
someone has ever used them.

Am 30.01.20 um 19:28 schrieb 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
>>>
>>
>