Search Issue Tracker
By Design
By Design in 1.8.X
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
- Required SpriteMask class (ID 331) is stripped when "Strip Engine Code" is enabled
- “Maximized serialized file backup not found” error is thrown when minimizing a window in a newly opened project
- Build stack trace contains invalid lines when building with IL2CPP using scripts with delegates containing generic types in the signature
- Entities Systems window has a “Show Full Player Loop” dropdown which does nothing when clicked after enabling “Show Full Player Loop”
- Entities Hierarchy Search “Show/Hide” button’s Lens Icon is blurry when the Editor is on an external monitor
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.
Resolution Note (1.8.X):
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.