[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2020-01-30 21:35:06
Message-ID: 5787db9b-e3f2-a131-e531-2a27cebadf3e () oracle ! com
[Download RAW message or body]

My obvious attempt failed to get any touch events delivered to the app. 
There is also code in GestureRecognizers (internal to glass) to register 
listeners for touch events that will then in some cases be turned into 
gestures, but it's disabled by default.

So it really does look like we are generating these low level macOS 
events for no purpose other than to cause the warning dialog on Catalina.

I'll do some more testing and will likely send out a PR for review to 
disable the low-level touch events on macOS 10.15 or later (option #2 
below). I'll also file a follow-up issue for 15 to fix it.

-- Kevin


On 1/30/2020 11:52 AM, Kevin Rushforth wrote:
> 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
>>>>>
>>>>
>>>
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]