Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)
mp at jugs.org
Thu Jan 30 18:55:23 UTC 2020
In this case I would also vote for #2. Your comment astonishes me
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
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  -- "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