-
Bug
-
Resolution: Unresolved
-
P3
-
jfx14
-
macOS
This is a follow-on bug to JDK-8231513.
Using CGEventTap on macOS to tap into the system event stream on macOS 10.15 or later causes a "Keystroke Receiving" security dialog to pop up with the following message:
"java" would like to receive keystrokes from any application.
In openjfx14 we fixed this by not using CGEventTap if the application is running on macOS 10.15 or later.
In openjfx15, we need to stop CGEventTap entirely, since there is not a sufficient reason to keep using it in the face of tightened security in macOS going forward.
It isn't at all clear that this code is was even really useful on macOS, since it is only used to generate low-level touch events for a touch screen, which aren't readily available to an application. As it stands, the only thing this does is generate a lot of internal touch events that aren't actually being sent to the application or otherwise being processed.
There are three possible solutions:
1. Remove the functionality entirely. This would involve removing the GlassTouches class and any calls to it.
2. Switch the code to use LocalEvent Monitoring, by calling addLocalMonitorForEventsMatchingMask. This requires enabling touch events for a particular view, since they aren't by default.
3. Process touch events in the same manner as mouse events and gestures as part of the normal event processing.
If we can conclusively prove that there is no way for a macOS application to get touch events, then option #1 is the best choice. Otherwise, we will need to do one of the other two options.
Option #2 will be less intrusive than option #3, so if it works then it seems the better choice. It should be as simple as replacing the CGEventTap code with LocalEvent Monitoring. The callback function will largely do the same thing it does today, and the changes will be mostly limted to the GlassTouches class. However, local event monitoring is per-View rather than global, so we will need to take this into account and make sure that the View is available everywhere we need it, or else have multiple instances of GlassTouches, one per View.
Using CGEventTap on macOS to tap into the system event stream on macOS 10.15 or later causes a "Keystroke Receiving" security dialog to pop up with the following message:
"java" would like to receive keystrokes from any application.
In openjfx14 we fixed this by not using CGEventTap if the application is running on macOS 10.15 or later.
In openjfx15, we need to stop CGEventTap entirely, since there is not a sufficient reason to keep using it in the face of tightened security in macOS going forward.
It isn't at all clear that this code is was even really useful on macOS, since it is only used to generate low-level touch events for a touch screen, which aren't readily available to an application. As it stands, the only thing this does is generate a lot of internal touch events that aren't actually being sent to the application or otherwise being processed.
There are three possible solutions:
1. Remove the functionality entirely. This would involve removing the GlassTouches class and any calls to it.
2. Switch the code to use LocalEvent Monitoring, by calling addLocalMonitorForEventsMatchingMask. This requires enabling touch events for a particular view, since they aren't by default.
3. Process touch events in the same manner as mouse events and gestures as part of the normal event processing.
If we can conclusively prove that there is no way for a macOS application to get touch events, then option #1 is the best choice. Otherwise, we will need to do one of the other two options.
Option #2 will be less intrusive than option #3, so if it works then it seems the better choice. It should be as simple as replacing the CGEventTap code with LocalEvent Monitoring. The callback function will largely do the same thing it does today, and the changes will be mostly limted to the GlassTouches class. However, local event monitoring is per-View rather than global, so we will need to take this into account and make sure that the View is available everywhere we need it, or else have multiple instances of GlassTouches, one per View.
- relates to
-
-
- Resolved
-