The bug was marked as “solved” in December. I cautiously waited for the “solved” versions of Unity to be released. I finally worked up the courage to go test it, and unfortunately, no it is not in any way solved at all.
This is now 9 months after I reported and Freddy said at that point Unity was already aware of the problem. So this problem is just sitting and no one is fixing it. I and many others absolutely need a working onscreen keyboard where we can control the way the input is shown on screen.
I repeat my request: If Unity is not willing to fix this, can you please share the code you are using for your partial/broken solution publicly so the community can try to work from what you started with and fix it instead? If I am unable to solve it with this information, I would even pay a considerable amount to a 3rd party Android developer to help find a solution as I am dead in the water without this being fixed for the project I have been working on the past 2 years.
I will not be able to release without a working on screen keyboard for the largest mobile operating system on earth.
Current Problems (Unity 2022.2.9f1 - Released: March 3, 2023)
I reopened the test project I submitted to Unity in this recent version as well as my real projects and found bizarre new behavior with this “fix”. Testing using Samsung S21 Android phone.
If this is actually “fixed” in a different version of Unity, please let me know which version I should be using as that would certainly be a nice quick solution. However, I presume this version has the “fix” as it is now behaving completely different than before. Just not correctly still.
1) TOUCHSCREENKEYBOARD.HIDEINPUT RESETS ITSELF TO FALSE WHEN KEYBOARD IS OPENED
Bizarrely, I noticed immediately I am no longer able to hide the input field at all. When I debug out, I can see that although my code clearly sets TouchScreenKeyboard.hideInput = true, something is constantly resetting this to false. I have my own internal bool I set in the test project above and it is not changing, but Unity keeps changing the assignment for the global variable beyond my control as soon as you activate the Keyboard.
Here I have in my Update() loop of the original demo project:
Debug.Log("UPDATE" + " | HIDE INPUT STATUS " + TouchScreenKeyboard.hideInput + " | HIDE INPUT BOOL " + hideInputField);
You can see for endless iterations (two shown here) it debugs out that both of these are “true” as I have set them to true on Awake() and none of my code will change this. Yet, as soon as I click the TextField at the bottom to open the keyboard, this then changes to false for no clear reason:
This should remain “true” for both as I have never told Unity to set it to false (I only ever told it to set it to true).
Thus this test project I submitted no longer even hides input at all. This is now what it looks like even after I set hideInput to true (it is no longer hidden, whereas before in the OP it would at least try to hide):
I suspect this is due to something in TextField resetting it, as in my real project where I am not using TextField but rather a custom made text field class, this does not happen.
2) ON PROJECTS WHERE HIDEINPUT REMAINS TRUE, THE SAME VISUAL ISSUES AND ERRORS REMAIN
As noted, on my main real project, hideInput does remain true in the same version of Unity. I believe this is because I am using a custom text field class I made rather than a standard TextField (which seems to now reset hideInput to false on clicking). Either way, at least this lets me see the other behaviors. Sadly, the problems reported seem to have changed a bit in behavior, but remain unresolved and this is still unusable.
One could presumably test this without TextField just by running TouchScreenKeyboard.Open as this is how I open keyboards in my custom text field.
*(i) Previously Reported: Blocked Clicks__*__
If I click in the region of the “hidden input”, my clicks are blocked from going through to Unity objects underneath but not always. Sometimes the 2nd or 3rd or 4th click goes through while the others are blocked. This is somewhat improved as previously clicking in this area would always crash the keyboard and at least now it does not always do so.
No errors are debugged out when these clicks don’t go through, so until I debug it further, I can’t say for sure if this is my problem or yours. Although the next issue suggests it probably still is. My guess is this issue would be fixed if everything else is fixed too.
Additionally, clicking in the “hidden zone” repeatedly can sometimes trigger a total application crash. I haven’t yet caught that on debugger to see why it’s happening. But something is likely still wrong here too.
(ii) [u]Previously Reported: Can Still See Autocorrect Lines[/u]
For example, here I have typed ‘hnv’ in a textfield in a scroll window above offscreen and the keyboard is trying to autocorrect me to “have” which is fine in the grey region where it should be, except it is still showing the blue autocorrect underlines for the imaginary suggestions in the “hidden” zone as previously reported was still an issue 9 months ago. This again shows there is still something there and it is still broken.
I am guessing this is related to the click blocking behavior above. If something is still there (which it clearly visibly is), it could still be blocking clicks too.
3) NEW OTHER ERRORS
When the TouchScreenKeyboard is open and Unity has set “hideInput” to false on its own accord (as in the original demo project for some reason now), there are still errors - they are just new ones I don’t recall from before. For example, if in the original test project you open the keyboard and then click any random place else on the screen, the keyboard collapses and it gives:
CONCLUSION
A couple final points:
- Mobile gaming now is a bigger industry than PC/console gaming: https://www.notebookcheck.net/Mobile-gaming-proves-to-be-a-gold-mine-as-it-racked-in-more-money-in-2021-than-PC-and-console-gaming-combined.597428.0.html
- Android has >70% global mobile OS share: Mobile OS market share worldwide 2009-2024 | Statista
- Unity, according to itself, powers >70% of the top mobile games: The All-in-One Game Engine to Create Mobile Games | Unity
I know that the challenge you voice is that you must interface with Android behind the scenes to move these unwanted objects off the screen. But compared to all the other things Unity has accomplished, I can hardly see this task as being so insurmountable as to cripple your entire organization and high quality coders. And if it is so challenging and insurmountable to you (which I don’t believe), please give us the code and let us work on it instead.
Either way, can we please, please, please have a working touchscreen keyboard with hideInput that allows us to design our apps appropriately in the way users expect?
BUG REPORT
The same test project from IN-9117 remains relevant. The only problem is now, as noted, this project is no longer sustaining hideInput = true and Unity is magically changing this to false for some reason. So you will not see the rest of the problems until you can fix that first. I cannot find any explanation for why hideInput remains true in my real project but no longer in this demo project.
I can submit it again with a new bug report but I am wary of doing so. It would be the same test project. It also takes about 6-9 months for a bug report to be “resolved,” and this “resolution” was anything but a resolution. I do not want to be stuck waiting another 6 months just to have someone look at it again for something we all already know is a problem and remains a problem.
Thanks for any help.