FlatList - Extreme scrolling breaks touches with focused TextInput #12976
Comments
|
Please take a look at this whenever you have the time @sahrens since its holding us back from moving FlatList to production. Our feeling is that its not just happening on extremely fast scroll, but thats a very easy way to reproduce it. It happens otherwise too just not deterministically. Cheers! |
|
iOS only? And you don't see the same problem with ListView and the same level of "extreme scrolling"? Very odd. I wonder if it could be related to event coalescing? @shergin - maybe you can take a look? |
|
I gave it another shot now that my scrolling hand is Usain Scrollt and could not make it happen with ListView nor Android. On Android I would sometimes run into #12884, but that's temporary and delays events, so different in nature from this permanent event skip. |
|
OMG, this bug report is so amazing! Thank you, @iggyfisk! |
|
I am facing a similar issue with my project. While the text input is focused 2 things happen : 1 => scrolling works as usual, so this is great I am not sure if it is the same problem you are facing, If not do you have a solution to this @iggyfisk ? |
|
That doesn't sound like the exact same thing @CheragV, once I break things by monster scrolling a FlatList, the onBlur handler on TextInputs still works as expected. It doesn't fire on the first touch after typing since that touch gets eaten by the bug. Either way my solution so far is to spend an hour doing retakes of a bug report video, then wait for the California boys to sort it out. |
|
I found an actual problem. The fix is coming! 🎉 |
|
What a hero @shergin! Looking forward to it! |
|
I'm also running into a similar issue where extreme scrolling of a |
…tter This PR fixes the problem originally introduced in facebook#6590 The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced. So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic. Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`: ``` We must be resilient to `targetInst` being `null` on `touchMove` or `touchEnd`. On certain platforms, this means that a native scroll has assumed control and the original touch targets are destroyed. ``` This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: facebook/react-native#12976 . The test also illustrates this problem.
…tter This PR fixes the problem originally introduced in facebook#6590 The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced. So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic. Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`: ``` We must be resilient to `targetInst` being `null` on `touchMove` or `touchEnd`. On certain platforms, this means that a native scroll has assumed control and the original touch targets are destroyed. ``` This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: facebook/react-native#12976 . The test also illustrates this problem.
|
Was fixed in 23c2a6c. 🎉 |
|
Thanks a lot for looking into it Shergin.
…On 20 Mar 2017 7:45 AM, "Valentin Shergin" ***@***.***> wrote:
Was fixed in 23c2a6c
<23c2a6c>.
🎉
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#12976 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABA-Y_LX8iTH4PGuy99QgX249Twa2Vvjks5rniCNgaJpZM4MfS1P>
.
|
|
Fixed as far as I could test, good hustle team! |
…tter This PR fixes the problem originally introduced in facebook#6590 The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced. So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic. Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`: ``` We must be resilient to `targetInst` being `null` on `touchMove` or `touchEnd`. On certain platforms, this means that a native scroll has assumed control and the original touch targets are destroyed. ``` This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: facebook/react-native#12976 . The test also illustrates this problem.
…tter This PR fixes the problem originally introduced in facebook#6590 The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced. So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic. Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`: ``` We must be resilient to `targetInst` being `null` on `touchMove` or `touchEnd`. On certain platforms, this means that a native scroll has assumed control and the original touch targets are destroyed. ``` This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: facebook/react-native#12976 . The test also illustrates this problem.
…tter (#9219) * Removed optimization for events without target in ReactNativeEventEmitter This PR fixes the problem originally introduced in #6590 The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced. So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic. Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`: ``` We must be resilient to `targetInst` being `null` on `touchMove` or `touchEnd`. On certain platforms, this means that a native scroll has assumed control and the original touch targets are destroyed. ``` This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: facebook/react-native#12976 . The test also illustrates this problem. * Prettier
Description
With a FlatList that has a fairly large number of items, sometimes you can scroll far/fast enough to permanently break something around TextInputs and touches. After "extreme" scrolling inside the FlatList, and after something is typed into a TextInput, the first touch outside the TextInput is swallowed. The second touch works as normal. It's hard to describe so I made a test project to reproduce and recorded a video to show every step and the resulting error.
The video is recorded using the iOS simulator, but the bug occurs on every iOS system we've tried so far, regardless of hardware or OS version. We have yet to reproduce it on Android.
We're not sure of the relevance of scroll speed, Y position, or number of items. Our live application has much fewer items than the test application in the video, but it's still easy to reproduce there. Probably because those items are more taxing on the hardware (images, different opacity etc). But that's all conjecture.
Either way this happens organically in our application and is preventing us from releasing our move away from ListView to production, which is a shame because overall the performance improvements with FlatList have been fantastic.
Reproduction
This repository contains the test application from the video above. scrolltest.js has all the relevant code.
Clone the repository,
npm install,react-native run-ios, quickly scroll through the list, type something in the text input and try the "Clear" button. I highly recommend watching the video so you'll know what I'm talking about.Additional Information
The text was updated successfully, but these errors were encountered: