Search Issue Tracker
Fixed in 2022.1.X
Votes
9
Found in
2017.4.0f1
2018.3.0a1
2019.1.0a1
2019.2.0a1
2019.2.0a10
Issue ID
1141591
Regression
No
[HoloLens] TouchScreenKeyboard doesn't report correct status or active values
Steps to reproduce:
1. Download 1141591_repro and open "new" scene
2. Enable XR and build a UWP project
3. Open Visual Studio solution and build the app for HoloLens
4. App launches with an opened keyboard. Close keyboard.
5. Check VS console
Results: when touch keyboard is closed TouchScreenKeyboard.active still returns TRUE and TouchScreenKeyboard.Status VISIBLE
Reproduced with: 2019.2.0a10, 2019.1.0b9, 2018.3.10f1, 2017.4.24f1
Note:
- not reproducible on HoloLens (in 2018.3 and 2017.4) when the app is launched in a non-XR mode
UPDATE:
This continues to be a sticking issue with Microsoft's Mixed Reality Toolkit (MRTK), and so reopening the bug to see if we can find a reasonable fix.
The problem is ultimately due to race-conditions with the WinRT InputPane API; it's a poorly designed API that causes all sorts of problems, but maybe a workaround is possible.
-
Bertrand78
Jul 24, 2019 09:47
Reproducible in 2019.1.9f1 on Hololens 2
-
arunraj_selvaraj
Jun 15, 2019 06:43
reproducible in 2018.4.f2 in XR mode(hololens-2). Any update on this ?
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
- The Scene View becomes gray and "NullReferenceException" errors are thrown when attaching the Unity Editor process to RenderDoc
- Memory usage rapidly rises when changing colors in the color wheel
- Physically Based Sky's Horizon and Zenith Tint Color Selection Bars don't have immediate access to color pickers
- EmptyAdditionalLightShadowmapTexture leaks from memory when URP quality level is changed using QualitySettings.SetQualityLevel
- Referenced ScriptableObject field does not get updated and cannot be set to "None" when there are no Objects of that type
Resolution Note (fix version 2022.1):
Due to some recent improvements to UWP's TouchScreenKeyboard implementation, we can finally fix this issue and active should only return true when the InputPane is actually visible.
NOTE: Due to the way Windows InputPane API works, TouchScreenKeyboard.active can still return true for a few seconds if you call Open on a device that has a physical keyboard attached, e.g. Surface. That is, when TouchScreenKeyboard.Open is called we'll "activate" the Windows InputPane (on-screen keyboard) but Windows has the final say on whether the keyboard actually shows or not. Unfortunately, the API doesn't inform us of Windows decision so we have to resort to a timeout before we'll revert the state back to "inactive".
In other words, if you try to pop the keyboard on a device that doesn't allow it, TouchScreenKeyboard will still report it as "active" and "visible" for up to 3 seconds before returning to the correct state.