BUG and handling in ios when the web mobile Fixed gets the focus in Input, fixedios

BUG and handling in ios when the web mobile Fixed gets the focus in Input, fixedios
1. symptom

You can see the following two figures. Figure 1 the search box of fixed is fixed on the top, and there is no problem in scrolling.

Figure 2 when the cursor enters the search box, ios intelligently positions the cursor in the middle, and the fixed attribute is automatically changed to absolute. When you scroll through the page, you will find that the search box of the original fixed is rolling along with the document.

Next, let's take a closer look at some of the features of ios. In order to center the input vertically and even scroll the scroll bar, the content of the first half of the product that we could not see was also leaked.

 

2. Refer to others' solutions

After searching on the Internet, most of them are reposted in this article, and even the matching pictures are based on others' Original:

Http://efe.baidu.com/blog/mobile-fixed-layout/

This solution mainly uses a div to wrap the entire part that can be rolled, and the part that cannot be rolled is fixed at the bottom, which is a good solution, unfortunately, my search box is not always fixed at the top. When the page is scroll below, the search box is positioned to the top. When the page returns to the top, the search box will disappear and I need to monitor the window. onscroll, ajax requests for automatic page flip, etc. In the end, this solution cannot be used. Even if you want to use it, the modification volume should be large.

 

After referring to the following article, I came up with a new idea:

Http://www.cnblogs.com/yexiaochai/p/3561939.html

 

3. New Ideas

As mentioned in the article,

We think of such a scenario, if we can monitor the keyboard behavior, if we can, we can
① When the keyboard pops up, set the fixed element to static (and finally set it to absolute)
② When the keyboard disappears, set the fixed element to fixed.

3.1 error attempts

Based on this idea, we conduct a series of tests. First, static means that the regression document, so that the entire search box cannot be found, because it may return to the bottom of the document. So static is not available. For absolute, you only need to set it to absolute and set the appropriate top. The idea is to obtain the top according to the scroll bar and then use $ (window ). height () is used to obtain the height of the visible area of the screen. It is estimated that the virtual keyboard is about half. Divide the value by 2 and then subtract the height of the search box to get the offset.

The last top = top-offset.

The idea is good. What is the effect. Observe Figure 2. We can guess that ios has moved the scroll bar. To ensure that the input is in the vertical center position, even if we set the top-offset for it, finally, ios rolled up again. I love and hate it. You are so smart. Why are you making such a BUG.

 

 

3.2 Final Solution

Return to Figure 2 for testing. When ios center input through the scroll bar, ios will not continue to monitor that input. In this case, we drag the page and the input will not return to the center, based on this idea, can we reset scroll through js delay for a while?

 

The solution is as follows:

1. Monitor the focus and blur events of input. When entering, set the search box to absolute;

2. Obtain the height of the current scroll and set it to the top of the search box;

3. Set the latency function and scroll the scroll bar to the current top;

4. restore the original fixed layout when the input is left.

 

Test iphone6s ios 9.x. No problem.

Android casually finds a colleague's vivo test. No problem.

Now I tested two mobile phones.

 

 

<! DOCTYPE html PUBLIC "-// W3C // dtd xhtml 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">