Search Issue Tracker
By Design
By Design in 1.8.X
Votes
0
Found in [Package]
1.8.1
Issue ID
ISXB-862
Regression
No
[iOS] Pointer class does not detect touches when tapping near the edge of the Screen
How to reproduce:
1. Open the attached Project "Raw Input Data"
2. Build and Run the Scene "SampleScene" on iOS
3. In the Build tap near the edge of the Screen
4. Observe the Xcode Console
Expected result: The position of the Touch is logged in the Xcode Console
Actual result: Nothing is logged in the Xcode Console
Reproducible with: 1.6.3 (2021.3.37f1), 1.7.0 (2021.3.37f1, 2022.3.24f1, 2023.2.19f1), 1.8.1 (6000.0.0b15)
Reproduced on:
- iPhone 13 (iOS 15.0)
- iPhone 12 mini (iOS 14.1)
- iPad Air 4th Gen (iOS 15.2.1)
Not reproducible on:
- iPhone 8 (user-supplied information)
- iPad Pro (2018) (user-supplied information)
Notes:
- Not reproducible with legacy Touch or EnhancedTouch functionality
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
- Objects with Universal Render Pipeline/Particles/Lit shader are always lit up when changing their Rendering Layer Mask
- PolySpatial “Trying to set shader on a Material Variant.” error is printed in the console when entering Play Mode
- Error “Shader error in 'YSCloudCover': call to 'tex3D' is ambiguous at Assets/YSCloudCoverText.shader(606) (on d3d11)“ is present when compiling tex3D shader with DXC
- Placeholder asset is not loaded with Advertisement Legacy sample when using the latest version of the package
- Addressables content build fails but the Player build is successful when building a development build
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.