Search Issue Tracker
Fixed in 2021.1.X
Fixed in 2019.4.X, 2020.2.X
Votes
0
Found in
2019.4
2019.4.0f1
2021.1
Issue ID
1256386
Regression
No
[UWP] XAML build shifts from App to a slate when TouchScreenKeyboard is used
How to reproduce:
1. Open the attached "TestKeyboard.zip" project
2. Build to UWP with XAML Build Type
3. Open Visual Studio solution
4. Build the solution to Hololens 2 (with ARM64 Remote machine deploy settings)
5. Start the text input
Expected result: Keyboard appears within the App
Actual result: Keyboard is pushed out of the App
Reproducible with: 2019.4.14f1, 2020.1.13f1, 2020.2.0b11, 2021.1.0a5
Notes:
- The issue was not reproducible on HL 1
- The issue does not appear in the D3D Build Type
- Could not reproduce on 2018.4, because of errors
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 (fix version 2021.1):
This is actually "By Design".
Originally with HoloLens, the Windows APIs (CoreTextEditContext) used to interface with the soft Keyboard wasn't supported, and so internal XAML forms were used as a proxy for entering text. Now, HoloLens properly supports these APIs and the UWP TouchScreenKeyboard was completely re-written to fully integrate the Keyboard with the Unity UI controls (InputField and TextMeshPro).
However, the "old" implementation is still around and used for XAML projects Going forward we'll remove the old keyboard code, and we "might* be able to backport the change to 2019 LTS, so long as it doesn't break anything.