cause
The input box of h5 causes the keyboard to have a bad experience. At present, even products such as WeChat, Zhihu, Baidu, etc. do not have good technical solutions. Especially when all the input boxes at the bottom are used, the experience is not very good. This problem is also a long-lasting problem. Currently preparing a set of native protocols to solve this problem. There is still something worth learning from in the project. Let me share it
I won't say much below, let's take a look at the detailed introduction
Business scenarios
Fixed input box at the bottom of h5 page
Whether it is used
<input />
still
<div contenteditable="true"> </div>
When the focus event triggers the native keyboard to be activated, the keyboard will pop up and block the input box on some iOS models (iphone 4s iphone 5, etc.), causing the user experience to be poor.
The current solution is to write a timed task. When determining that it is ios to open the page, execute the following function
let timer = setInterval(()=>{
// container knows the dom node of the entire container ({
block: 'start',
behavior: 'auto'
})
},300); //300Milliseconds are the values obtained after multiple tests，User experience is best
About scrollIntoView
The official explanation of scrollIntoView API is
The () method scrolls the element on which it's called into the visible area of the browser window.
grammar
(); // Equivalent to (true)(alignToTop); // Boolean type parameters(scrollIntoViewOptions); // ObjectType parameters
parameter
| parameter | illustrate | type | Optional value | default value |
|---|---|---|---|---|
| alignToTop | -- | boolean | --- | false |
| scrollIntoViewOptions | -- | object | -- | -- |
{
behavior: "auto" | "instant" | "smooth",
block: "start" | "end",
}
Compatibility of scrollIntoView found in can i use (I don't consider in mainstream browsers)
- Firefox 36 or above compatible
- chrome 61 or above compatible
- safiri 5.1 starts incompatible with smooth in behavior
Follow-up questions
Of course, this solution intelligently solves the problems of some models, and to truly solve this problem, we still have to rely on the native end.
Problems in iOS and Android models
Because this timing task is set up, there will be a subsequent problem, which has also been encountered in the implementation project. Let me explain it here.
When pulling up or pulling to the head, the background will appear white, because with this timer, it will constantly pull the view back, causing the page to jitter.
If you do webview prohibits dragging in the app layer, you will not have this problem. Of course, you cannot rely entirely on the app. We also need to do compatibility optimization in this aspect in the program.
<div class="container" @touchStart="touchStart($event)" @touchEnd="touchEnd($event)"> </div>
touchStart(e) {
();
},
touchEnd(e) {
();
},
clearTimer() {
if() {
clearInterval();
= null;
}else{
return;
}
},
repairIosInput() {
if() {
return;
}
= setInterval(()=>{
({
block: 'start',
behavior: 'auto'
})
},300);
}
Clear the timer when starting to pull the page, and turn on the timer when stopping pulling, so that the problem of jitter can be solved.
Summarize
As a long-lasting problem, more solutions will be used. Please contact me and discuss together to get out of the trap as soon as possible!
Okay, the above is the entire content of this article. I hope that the content of this article has a certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support.