At the interactive level, the process of completing a feature (obtaining the desired information) is called the user path. The longer the user path, the more complex it is to complete the functionality and the worse the user experience. Therefore, when opening a form interface that requires the user to fill in information, in order to improve availability, the PC terminal will generally focus the cursor on the corresponding input box (input), and the mobile terminal will also focus the corresponding input to arouse the soft keyboard, which is convenient for the user to directly enter. Regardless of the PC scenario, this seemingly insignificant effect can be achieved on mobile devices (iOS, Android) after a lot of work. Let’s take a look at the following three common scenarios.

First, when entering the form page, let the soft keyboard open automatically

This requirement is common, but it’s also the trickiest. Scientifically speaking, we can get the input directly from JS, and give it focus. But t that doesn’t work in mobile browsers. In addition, H5 provides the Autofocus attribute. The compatibility of this attribute on Caniuse does not support iOS Safari, and Android will not support it until 4.4, so we can ignore this attribute, but we will mention it again below. So in iOS, it’s not practical to automatically focus input after the page load is done and open the keyboard. The saddest thing is that Android does not work either. At present, a simple test has been conducted on WebView embedded in browser and App. Input in H5 is in focus state, but it cannot evoke keyboard, keyboard, keyboard… Scenario 1, no solution is available…… (It can be implemented in Hybrid App as mentioned below)

Click on an element on the page to invoke the soft keyboard

This is an additional user interaction step compared to scenario 1. So is it possible to use JS to successfully invoke the keyboard on iOS? The answer is yes.

<! -- HTML --> <input id="input" type="text" placeholder="this a input"/> <button id="J-focus-btn" onclick="clickFocusBtn()">focus input</button> // JS function clickFocusBtn() { document.getElementById("input").focus(); }Copy the code

If you’re using Zepto, be aware that for iOS, you can’t use tap events.

// JS  zepto
$('#J-focus-btn').on('tap', function() {
    $('#input').focus();
});
Copy the code

The zepto Tap event used above does not work as expected on iOS, which involves a default security mechanism in the iOS WebView. There’s a property in UIWebView:

@property (nonatomic) BOOL keyboardDisplayRequiresUserAction NS_AVAILABLE_IOS(6_0); // default is YES

This property defaults to YES, which means that the keyboard must be in user interaction. Zepto triggers tap events within setTimeout, which means that the execution environment is not triggered by the user when focus is executed, so focus is blocked.

// zepto 
tapTimeout = setTimeout(function() {
   // trigger event
}, 0)
Copy the code

If we were to write Hybird App page, you can let the Native Coder will UIWebView keyboardDisplayRequiresUserAction attribute is set to NO, don’t have to worry about this problem. WKWebView on iOS does not support this property, but there is a solution on StackOverflow to use the Runtime method swizzling hack. See this link stackoverflow.com/questions/3… Then scene 1 can be realized in the Hybrid App. Of course, we can’t do anything with the native Safari browser of the system, so we can optimize it a little bit. Tested the autofocus attribute at the same time, in the case of keyboardDisplayRequiresUserAction set to NO, it is also can work normally. Under Android, it is also possible to achieve the effect of focus input after the user clicks, and there is no iOS mechanism.

3. Automatic focus of multiple inputs in a form page

This scenario is actually a combination of scenario 1 and scenario 2. Based on the test analysis of the above two scenarios, it can be realized by relying on Native WebView in my * iOS Hybrid App *, and automatic focusing except for the first focus can be realized in Android and external browsers. The iOS UIWebView set keyboardDisplayRequiresUserAction = NO, need to delay in the blur event focus to work (for reasons unknown temporarily) :

// Hybrid App document.querySelector('#input1').focus(); document.querySelector('#input1').addEventListener('blur', Function () {setTimeout(function() {document.querySelector('#input2').focus(); }, 200); });Copy the code

Within the system Safari, because keyboardDisplayRequiresUserAction defaults to YES, so do not allow outside the execution environment produced by the user interaction calls focus, so cannot be delayed.

// System Safari document.querySelector('#input1').focus(); document.querySelector('#input1').addEventListener('blur', function() { document.querySelector('#input2').focus(); });Copy the code

On Android, autofocus is still just a cursor, no keyboard… There is no problem with the subsequent autofocus, as shown in the following picture…



To solve this problem, JSBridge can be used to evoke Android native in Hybrid App, and refocus in subsequent blur events does not need to be processed by native.

InputMethodManager imm = (InputMethodManager) getSystemService(context.input_method_service); imm.showSoftInput(view, 0); // View is the current WebViewCopy the code

summary

Summary:

  • To implement page load after the completion of the automatic focusing to the input and the pop-up keyboard, will rely on the iOS App WebView keyboardDisplayRequiresUserAction set to NO, you can support. Android can only rely on JSBridge to call Android native methods to invoke the keyboard.
  • Click on the focus element to specify input. This is supported on both iOS and Android, but iOS must ensure that focus is called directly in the context of the user’s action event (Zepto Tap pit).
  • Focus on input, iOS is a bit special, see scenario 3 above…

LINKS

  • mobile-safari-autofocus-text-field
  • wkwebview-cant-open-keyboard-for-input-field