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

This article mainly introduces how to solve the problem of non-return of the interface when the IOS keyboard is put away through focusout events, which has a certain reference value, and interested friends can refer to it. I hope you can learn a lot after reading this article.

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 screenshot is as follows:

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 when * input boxes blur. So let's modify our code so that when this happens, we can cut off the behavior of * input boxes. 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 }} Thank you for reading this article carefully. I hope the article "how to solve the problem of non-return of the interface when the IOS keyboard is closed through focusout events" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.