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

Michael Paus mp at
Thu Jan 30 18:55:23 UTC 2020

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 
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]

More information about the openjfx-dev mailing list