Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge points about how to solve the problem of putting away the interface of the IOS keyboard in html. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look.

Problem symptom

Today, when developing a mobile H5 page, I encountered the problem that the interface could not be returned when the keyboard was folded on the IOS. The problems and symptoms are described in detail below:

Page structure

The page in question is a form structure. That is, it is similar to the structure of four input forms under a div for users to fill in mailing information. Similar to:

The page automatically moves up when the keyboard pops up.

When the user enters the contact number on the phone, the IPhone keyboard pops up, and the iphone moves the entire page up in order to allow the user to see the phone input box (otherwise the keyboard will cover the phone input box). At this point, the top of the page is actually part of the distance from our viewport (we see a line of input boxes disappear from the interface).

The page cannot be restored when the keyboard is folded

However, when the user has finished typing and shuts down the keyboard, the keyboard is put away, but the page position is not restored.

Analysis of problems

In fact, this is because the part of the page that rolls out of the viewport does not fall when IOS cannot close the keyboard. At this point, the user can drag the page back through his fingers.

But after all, the experience is not good.

To solve this problem, we can call window.scrollTo (0,0) to scroll the page to the top of the viewport when the user's cursor leaves the input box.

So the problem now is to add blur events to all four input boxes in the form, and then call window.scrollTo in handler. However, whether you add it through Vue's @ blur or through the DOM operation, it's not elegant to add four event listeners. Naturally, we thought of using event proxies.

Event agent

That is, we put the event listener on the top element; then we define a function of inputBlur to wait for the trigger.

As a result, it was found that our event listener could not be triggered. The reason is that the blur event of the input box cannot bubble.

A solution that can't bubble.

After querying, it is found that the two DOM events, focus and blur, cannot bubble in the specification. Similarly, there are two other events, focusin and focusout, which can bubble.

Some articles on the Internet have mentioned that focusin and focusout are a kind of DOM events supported by IE browsers. In fact, when we look at the MDN documentation, we find that these two events have become a standard of the DOM 3 specification, and there are a large number of browsers that can be supported.

So, to solve the problem decisively through these two events, we changed it to focusout

Then, implement our event handler:

InputBlur (e) {/ / first of all, determine whether the target element that triggers the event is the input input box, and we only focus on the behavior of the input box. If (e & & e.target & & e.target.tagName & & e.target.tagName.toLowerCase () = 'input') {window.scrollTo (0);}}

At this time, our problem is solved, when we enter the content from the input box, and then click the completion of the keyboard to put away the keyboard, the effect is in line with our expectations.

However, after testing the mobile phone, it is found that the page will wobble when we switch directly from the phone input box to the name input box. Let's continue the analysis.

Solve the jitter problem

In fact, the reason for the jitter when the two input boxes are switched is also very simple. Because when we switch between the above two input boxes, the page will first trigger the blur event of the phone input box, and then trigger the focus event of the name input box. In this case, our window.scrollTo (0J0) is triggered during blur, causing the page to scroll down, then the name input box is focused, and the keyboard continues to pop up-which causes the page to move up again.

In fact, when switching between two input boxes, there is no need to trigger the window.scrollTo behavior of the first input box blur. So let's modify our code so that when the input box switch occurs, we can cut off the behavior of the first input box. Here we use setTimeout to solve the problem:

InputBlur (e) {/ / first of all, determine whether the target element that triggers the event is the input input box, and we only focus on the behavior of the input box. If (e & e.target & & e.target.tagName & & e.target.tagName.toLowerCase () = = 'input') {/ / the input box loses focus and you want to restore the scrolling part of the IOS keyboard out of the page. Scroll the page to the top of the window to align console.log ('set timer') this.timer = setTimeout (() = > {console.log (' timer trigger') window.scrollTo (0mem0) }, 0)}}, inputFocus (e) {/ / if focus, remove the timer if (e & e.target & & e.target.tagName & & e.target.tagName.toLowerCase () = = 'input') {clearTimeout (this.timer) of the previous input box }} these are all the contents of this article entitled "how to solve the problem of IOS Keyboard put-away Interface in html". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.