Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)
kevin.rushforth at oracle.com
Thu Jan 30 19:52:47 UTC 2020
Yeah, I was surprised, too. I can see the low level touch events being
generated and passed up to the Java code, but I haven't actually
verified yet that it turns them into JavaFX TouchEvents that get
delivered to an application (I'll try that this afternoon).
On 1/30/2020 10:55 AM, Michael Paus wrote:
> 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  -- "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