Search Issue Tracker
By Design
Votes
1
Found in [Package]
1.8.2
1.11.2
Issue ID
ISXB-990
Regression
No
Input starts with the “Ended” phase when touching a side of a screen if using the New Input System on iOS devices
How to reproduce:
1. Build And Run the user’s attached “InputSystemBug.zip” project on an iOS device
2. In the app, press on the side of the device’s screen
3. Observe the console
Expected result: Logged input starts with the “Began” phase
Actual result: Logged input starts with the “Ended” phase
Reproducible with: 1.3.0 (2021.3.0f1), 1.8.0-pre.1 (2021.3.31f1, 2022.3.11f1, 2023.1.18f1, 2023.2.0b15, 2023.3.0a11)
Reproduced on:
VLNQA00494 - iPhone 14 Pro Max, 16.3.1 iOS
VLNQA00358 - iPhone 12, 14.1 iOS
VLNQA00392 - iPad (9th generation), 15.0 iOS
VLNQA00310 - iPad Pro 12.9", 13.4.1 iOS
iPhone 14 Pro Max, 16.4.1 iOS (user’s info)
iPhone 11, 16.6.1 iOS (user’s info)
iPhone 8 Plus, 14.1 iOS (user’s info)
Not reproducible on:
VLNQA00267, Samsung Galaxy S10+ (SM-G975F), Android 12, CPU: Exynos 9 (9820), GPU: Mali-G76
VLNQA00120, Google Pixel 2 (Pixel 2), Android 8.1.0, CPU: Snapdragon 835 MSM8998, GPU: Adreno (TM) 540
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- "Modifying the parent of a VisualElement while it’s already being modified is not allowed" error is thrown when entering text and pressing tab in the Search window
- Mesh colliders are not updating their positions of bounds correctly
- Images are missing from the "Open the sprite editor" documentation for 6.0, 6.1 and 6.2
- The previous element in the array is modified when assigning an Asset to a new element of AssetReferenceT
- Unity Perforce Integration: VCS Connection Active State Fails via CLI with Valid Inputs
Resolution Note:
The issue here is that gestures on the edges of phones withhold touch information until the touch is released. This detects a "touch press (TouchPhase::Began" and "touch release (TouchPhase::Ended) " in the same frame.
In Input Legacy we did delay the TouchPhase::Ended to the next delay but we purposely don't do that by default with the Input System. Here's the reasoning from our code comments (see https://github.com/Unity-Technologies/InputSystem/blob/4e8347ae838f01b283d331a2e2a3b841d58e72cc/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs#L599-L610)
NOTE: We do NOT make a effort here to prevent us from losing short-lived touches. This is different
from the old input system where individual touches were not reused until the next frame. This meant
that additional touches potentially had to be allocated in order to accommodate new touches coming
in from the system.
The rationale for NOT doing this is that:
a) Actions don't need it. They observe every single state change and thus will not lose data
even if it is short-lived (i.e. changes more than once in the same update).
b) The higher-level Touch (EnhancedTouchSupport) API is provided to
not only handle this scenario but also give a generally more flexible and useful touch API
than writing code directly against Touchscreen.
The alternative is to use the EnhancedTouch API provided with the Input System (see https://docs.unity3d.com/Packages/com.unity.inputsystem@1.11/manual/Touch.html#enhancedtouchtouch-class)
In this case, if a short-lived tap is done within a frame, this API "records the history" of all touch state changes and will in fact delay the Ended phase into the next frame.