H5 keyboard compatibility summary

In H5 projects, it is common to see a page with a single or even multiple input/ Textarea fields and fixed elements at the bottom. When the input/ Textarea input box gets focus, it will automatically trigger the keyboard pop-up, which is not the same in ios and Android WebView, and there is also a difference when we actively trigger the keyboard collapse. In any case, we want to keep the user experience as consistent as possible while maintaining smooth functions, so we have the following series of compatibility problems.

1. Different performances of keyboard pop-ups

  • IOS: the IOS keyboard is at the top of the window, when the keyboard is up, the height of the WebView does not change, but the scrollTop changes, and the page can scroll. The maximum scrolling value of a page is the height of the keyboard that pops up. If the page happens to scroll to the bottom when the keyboard pops up, the scrollTop change value is the height of the keyboard, and in other cases, it cannot be obtained. This makes it difficult to get the true height of the keyboard on IOS.
  • Android: WebView space, the space is less than or equal to the keyboard space, the height difference will change with the layout and different, some thinkKeyboard height + page height = original page height;Is a false and misleading formula that can only be applied in the case of a very coincidental layout.

2. Different manifestations of keyboard folding

  • IOS: When a button on the keyboard is triggered to close the keyboard or a page area outside the input box, the input box loses focus, so the blur event of the input box is triggered.
  • Android: When the button on the keyboard is triggered, the input box does not lose focus, so it does not trigger the blur event on the page. When a region outside the input box is triggered, the input box loses focus, triggering the blur event of the input box.

3. Monitor the eject and collapse of the keyboard

Currently, there is no interface in H5 that can directly monitor keyboard events, but we can judge whether the keyboard is popping up or folding up by analyzing the triggering process and expression form of the keyboard.

  • Keyboard popup: when the input box gets the focus, it will automatically trigger the keyboard popup action. Therefore, we can monitor the focus event of the input box and realize the page logic required after the keyboard pops up. This is consistent on ios and Android.
  • Keyboard retract: From Part 2, we know that different forms of triggering keyboard retract have different performance. When triggering other page areas to retract keyboard, we can listen to the blur event of the input box and realize the page logic required after keyboard retract. However, there are differences between ios and Android terminals when the keyboard is folded by keyboard buttons. The following is a detailed analysis:
    • IOS: The input box blur event is triggered, but still listens through this method.
    • Android: There is no blur event to trigger the input box. However, through part 1 and 2, we can know that in Android, the state switch of the keyboard (pop up and fold up) is not only associated with the input box, but also affects the change of webView height, so we can judge whether the keyboard fold up by monitoring the change of Webview height.

For example, the page contains an input box:

<div class="txd"> 
	Welcome to TXD!  
</div>
<div class="input">
	<input id="input" type="tel" />
</div>
Copy the code

Ios & Android keyboard pop-up:

const $input = document.getElementById('input');
$input.addEventListener('focus', () => {// handle the page logic required after the keyboard pops up},false);
Copy the code

Ios keyboard down:

const $input = document.getElementById('input');
$input.addEventListener('blur', () => {// handle the page logic required after the keyboard is folded up},false);
Copy the code

Android keyboard pops up and down:

/ * keyboard pop-up page height decreases after * / const originHeight = document. The documentElement. ClientHeight | | document. Body. ClientHeight; window.addEventListener('resize', () => {
	const resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
	if(resizeHeight < originHeight) {else{// the page logic required after the keyboard is up}},false);
Copy the code

In practice, determine which method to use by judging userAgent:

const ua = window.navigator.userAgent.toLocaleLowerCase();
const isIOS = /iphone|ipad|ipod/.test(ua);
const isAndroid = /android/.test(ua);
Copy the code

Use cases

Following are several common scenarios based on the above discussion:

(1) The head and middle input boxes are in the normal document flow, and the bottom element is fixed

Ios keyboard cover on the page, the page height is always the same, the page can scroll, the bottom element is blocked;

Android page height is reduced, the page is not scrollable, fixed element bottom attribute baseline for the keyboard;

(2) The header and input box are in the normal document flow and occupy a larger visible area, while the element at the bottom is fixed

On ios, the height doesn’t change and the page can scroll;

Android page height is smaller, but in order to enable normal document flow elements can be displayed properly, the page can scroll up and down, fixed element bottom attribute baseline is the keyboard;

(3) The head is in the normal document flow, and the input box is fixed bottom from the normal document flow


Ios height does not change and the input box is always visible;

Android page height becomes smaller, the page cannot scroll, fixed input box bottom attribute of the baseline keyboard;

5. Summary

  1. In ios, whatever the layout, in order for the input field to appear in the visible area, the page scrolls up when the keyboard pops up, The process and Element. ScrollIntoViewIfNeeded () method (will not in the visible region of the browser window elements, scroll to the visible region of the browser window) the effect of the agreement; And the height is always the same, the page can be scrolled.
  2. In Android, after the keyboard is invoked, a page can be scrolled or not by its elements in the normal document flow: if the elements in the normal document flow can be displayed in full, the page cannot be scrolled, otherwise the page supports scrolling;
  3. In Android, the base of fixed elements changes after the keyboard is invoked: the base of elements positioned at bottom changes to the top of the keyboard; Elements positioned according to top are still positioned according to the top of the page, so some elements can be positioned according to the top and some can be positioned according to the bottom to accommodate normal document flow and user experience of fixed elements.

It will be easier to deal with compatibility issues once you understand the nature of the keyboard’s pop-up fold in the H5. . At the same time also can use Element scrollIntoViewIfNeeded () method of the auxiliary problem solving (such as switch in different input method, can lead to useful information obscured) optimization experience.