Forum Discussion

🚨 This forum is archived and read-only. To submit a forum post, please visit our new Developer Forum. 🚨
lostsomfan's avatar
lostsomfan
Protege
6 years ago

Unity > Inputfield UI turns Quest black for a moment.

On Oculus Go we found out they didn't give access to android keyboard (which standard android provides with), so it pops up a green "error" in lower area of headset and we solved it with our own virtual keyboard - anyway... In Quest when you click and hightlight / focus an inputfield - it turns Quest totally black and starting to "fake load" something. Anyone got a solution for this error? 

Unity 2018.3 -

10 Replies

  • Agreed, working on Quest right now -- selecting a TextMeshPro InputField or a regular Unity InputField pops up the loading ellipsis and turns the screen to black, until I point away from where it is (still in the black screen) and click again to deselect, and that takes the black screen away but not the ellipsis.
  • Yes, it's better to write a customised input field to get rid of this problem.
    VR UIKit has a virtual keyboard that could work with their customised input field. I've tested it, and it works like a charm.


  • yunhan0 said:

    Yes, it's better to write a customised input field to get rid of this problem.
    VR UIKit has a virtual keyboard that could work with their customised input field. I've tested it, and it works like a charm.



    I am using that exact kit for our form and it still has the issue. Can you post a picture of your unity setup? 
  • @"davido.tucciarone" There’s mobile input and keyboard in the latest version. Use the keyboard and input in Prefabs/Mobile folder instead of the keyboard in Prefabs/Keyboard folder. The mobile keyboard only works with their CustomisedInputField. You can have a look at the example FormKeyboard-L1 in the Prefabs/Mobile/Keyboard folder.
  • i used a button instead of inputfield, when i click on button/fake_inputfield it targets the child text component so it acts like a inputfield. good for now (looks identical) but they should fix the real inputfield bug
  • I tried editing the AndroidManifest.xml to prevent the Quest from trying to access the non-existent native keyboard, although even that method proves difficult on android tablets, but to no avail.
    <activity ...
    android:configChanges="keyboard|keyboardHidden ...
    or
    android:windowSoftInputMode="stateHidden" ...

  • Here is a concept I've used for an android webapp to programmatically close the soft keyboard when submitting a form (without an event.stopPropagation kind of thing):
    <form>
    <input type="email" placeholder="Your Email" [disabled]="isSubmitting"/>
    <input type="password" placeholder="Your Password" [disabled]="isSubmitting"/>
    <button [disabled]="isSubmitting" (click)="submitForm($event)">LOG IN</button>
    </form>
    <script>
    submitForm(event: any): void {
    var elem = event.target;
    elem.focus(); // If a form field, draw focus to the submitBtn so the soft keyboard will close
    elem.blur(); // Blur the standalone field so the soft keyboard will close or
    // remove highlight from the submitBtn
    isSubmitting = true;
    //...
    }
    </script>


  • UnityEngine.UI.InputField's ActivateInputFieldInternal method calls static methods from UnityEngine.TouchScreenKeyboard including 1) TouchScreenKeyboard.Open: which attempts to create a native keyboard instance and tries to render it (I believe is causing the three dots error, extern) when 2) TouchScreenKeyboard.isSupported: which is (incorrectly for Quest) true due to Application.platform of Android.
    Surprisingly, InputField.readOnly is not taken into account when determining if it should call Open.
    InputField.shouldHideMobileInput refers to an open or closed collapsible header of sorts (available on some tablet OS) on the already open soft keyboard.

    OVR's UIHelpers allows use of the InputField's caretSelection, which is the benefit versus a button.