Fix a randomly reproduced keyboard issue after thinking (Reactnative)

This article shares a discussion about fix a randomly reproduced keyboard issue after thinking, very meaningful, interested friends can look at

Recently spent nearly a week fix a mobile bug, is a very interesting bug, presumably. It's a long story, and it's interesting to keep looking.

What kind of bug is it?

The behavior of the bug is that after a tablet-side app has been used for a long time , first, after entering some content in the input box, click Done/search, Second, then click on some blank area of the page, the soft keyboard pops up, and the cursor focus the input box that has been entered recently .

The application's response to user behavior is confusing and confusing to the user at this point.
In summary, it has the following several characteristics

• Application is normal at first, not always reproducible

• Once this bug occurs, there is a problem with every page that has an input box.

• The reproduced scene is unknown, it is now known that the longer the application is used, the easier it is to appear, and the application will disappear once the background shuts down and the disease restarts.

How to fix this bug

The first step is to stabilize and re-

We first tried to find a minimal user journey to reproduce the bug, when the luck was better, spent about half a day to find a minimal recurrence path.

Not to mention the business background, simple introduction of the application of the page logic.
Our app has a home page after login, home page exists three tab can swipe or click Switch, there are some function menu on the tab page, one of the function menu Menua can click to jump to another new page with an input box.
The page is probably the following, not professional UX very ugly not to be offended.

One of the paths we've found that can be quickly reproduced is

• After landing on the home page, repeatedly switch three tab multiple times (more than 20 times)

• Click Menua to arrive at a page with an input box

• Enter data in the input box and click Done on the soft keyboard

• Click on the blank area of the page

Then the soft keyboard comes out.

The second step is to try to find out from the Code section why the smallest scenario is problematic

After finding a minimal repro path, we can find out from the code why this problem occurs.
Since this bug has not been applied after the restart, we suspect that the direction is positioned on the issue of render, the approximate rate is on the component.
There's a few guesses between us.

• There is a problem with your own encapsulated input component

• There is a problem with the sliding components of the three tabs, and the scroll view in the sliding assembly affects the RN gesture Response system

Finally found seemingly are not, this time and the group of another colleague pair, she found in the request is more prone to problems, the middle also suspected network request processing caused. This suspicion is not quite right, but it does find a way for us.

We finally found out that all of our network requests have a mask mask on the page before the request results are returned and a loading hint symbol like the web inside spinner (Activityindicator in Rn), This section will affect the page render.
Instead of removing this part (without a mask before the request arrives), the bug is gone, and the discovery was shocking and confusing, because it seems to have found some reason but we still don't understand why.

Third step attempt to repair (without knowing the root cause of the case)

With the hint of this idea, we try to fix it. According to business requirements, we can not cancel the use of Activityindicator, because it is really necessary to give the user appropriate hints.

We tried to modify the mask implementation, and in the old we used a third-party RN component react-native-root-siblings to help us insert a sibling element in the root sibling to display our loading hint symbol.

Typically, before the result of a request request is reached, we insert a new sibling element, which is removed when the request is complete. At that time, because this part of the repeated modification of the element structure of the page, the logic of the new-destory into the new-update logic, reducing the element modification. Update is just to let activityindicator not appear to be hide.

Fourth step test whether the bug can be reproduced again

We want to fix this bug by reducing the repeated deletion of page elements, what about the result?
Incredibly mysterious very difficult to reproduce, we are very happy, although still did not understand the reason.
After QA said on the real machine still met several times, let us is more puzzling, inexplicable is the probability of appearing is really less, but why still appear?

Fifth step analysis of the root cause of the bug

This time we need to understand the real cause of the bug.
We are back to the performance of this bug, why clicking on the blank area will trigger the TextInput focus method? We tried to do such a few things.

• Find out where the focus will trigger the textinput.

Except in the code logic, a small amount is passed by binding ref and then triggered. The focus method (because it is a small number of occurrences, does not conform to the scenario where all input is affected by this bug, and the quick exclusion is not part of the reason), we found that there are many places in the TextInput component of Rn that are called into the focus method.