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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
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.