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

[Kevin Rushforth]

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).

-- Kevin


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