Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)
kevin.rushforth at oracle.com
Thu Jan 30 18:28:16 UTC 2020
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.
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  -- "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
>> 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
>>  https://bugs.openjdk.java.net/browse/JDK-8231513
More information about the openjfx-dev