Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Prioritise UITapGestureRecognizer on interop views with
Cooperative
…
… interop mode. Prioritise UIScreenEdgePanGestureRecognizer on ascendant views. (#1695) Before that change taps on interop views with cooperative mode would be discarded by compose, which expects non-discrete gesture holding on a point before failing and redirecting touches sequence to the interop view. The requirement of holding ultimately made the tap gesture impossible due to its requirement of being a short press/release sequence, which contradicts the compose heuristics. This scenario is fixed in this PR by allowing precedence of `UITapGestureRecognizer` over other recognisers. Since most of the native `tap`/`double tap` interactions are built on top of `UITapGestureRecognizer` it should improve the UX for default interop properties with stable constructor setting the interaction mode to be `Cooperative`. Coincidentally this change inspired a cheap fix for interactive pop bugs. Resolves https://youtrack.jetbrains.com/issue/CMP-6683 Fixes https://youtrack.jetbrains.com/issue/CMP-6622/Gestures-dont-work-on-native-ios-view-embedded-with-UIKitView-for-compose-1.7.0-beta01 Demo: https://github.com/user-attachments/assets/8b679ff0-6edd-42c3-9839-fe4e14cc4dff ## Testing - Taps on interop views with cooperative interaction mode are properly registered now and processed by native UITapGesture recogniser attached to that view. - Interactive pop on `UINavigationController` should not get stuck in an awkward state preventing the gesture. This should be tested by QA ## Release Notes ### Fixes - iOS - Taps should be properly registered on interop views with `UIKitInteropInteractionMode.Cooperative` interaction mode. - Interactive pop on `UINavigationController` should recognize correctly.
- Loading branch information