Ignore events fired on missing React Native instances #6590
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This can happen if something gets unmounted before the event gets dispatched. I'm not sure how this works out exactly but this preserves previous behavior in this scenario.
|
cc @spicyj This is different from the responder scenario. I believe this can happen if two events are processed after each other and the first one removes the thing that fired on the second one. |
|
This likely conflicts with whatever change we'll make for the responder code. In the case I was testing, |
|
Wouldn't the responder stuff have to ensure that the instance is kept alive in this map? Or just use a different path. How else would you fire it? |
|
Not sure yet. :\ |
|
I believe this is a behavior change and we previously bubbled based on the removed node's former hierarchy. This brings the behavior in line with React DOM though so I'll accept it. |
|
I see. Yea. That'll be interesting. If we switched to JS hit detection it would presumably be based on the new hierarchy. |
|
Hm. I think this behavior change could actually be pretty bad. If you remove things as you're dragging/touching on a surface we'll start dropping those events and it can be glitchy. |
|
Does the DOM actually end up with this problem? Isn't hit detection done for each new event so if something is removed between them we would have a new target? We could save the event bubbling path on the native side and send each tag in the path over the bridge. |
|
For mouse events there is a new target each time; not for touch events. |
ghost
pushed a commit
to facebook/react-native
that referenced
this pull request
Apr 26, 2016
Summary: Sync new React fixes. Includes... facebook/react#6584 facebook/react#6587 facebook/react#6588 facebook/react#6590 Since this require PanResponder to be restored I also included D3210771 here. Reviewed By: spicyj Differential Revision: D3221285 fb-gh-sync-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e fbshipit-source-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e
ptmt
pushed a commit
to ptmt/react-native
that referenced
this pull request
May 9, 2016
Summary: Sync new React fixes. Includes... facebook/react#6584 facebook/react#6587 facebook/react#6588 facebook/react#6590 Since this require PanResponder to be restored I also included D3210771 here. Reviewed By: spicyj Differential Revision: D3221285 fb-gh-sync-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e fbshipit-source-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e
zebulgar
pushed a commit
to nightingale/react-native
that referenced
this pull request
Jun 18, 2016
Summary: Sync new React fixes. Includes... facebook/react#6584 facebook/react#6587 facebook/react#6588 facebook/react#6590 Since this require PanResponder to be restored I also included D3210771 here. Reviewed By: spicyj Differential Revision: D3221285 fb-gh-sync-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e fbshipit-source-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e
bubblesunyum
pushed a commit
to iodine/react-native
that referenced
this pull request
Aug 23, 2016
Summary: Sync new React fixes. Includes... facebook/react#6584 facebook/react#6587 facebook/react#6588 facebook/react#6590 Since this require PanResponder to be restored I also included D3210771 here. Reviewed By: spicyj Differential Revision: D3221285 fb-gh-sync-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e fbshipit-source-id: cbb6b1dd0fd0443d246957ceb94b6a424c09c24e
shergin
added a commit
to shergin/react
that referenced
this pull request
Mar 19, 2017
…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.
shergin
added a commit
to shergin/react
that referenced
this pull request
Mar 19, 2017
…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.
shergin
added a commit
to shergin/react
that referenced
this pull request
Mar 20, 2017
…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.
shergin
added a commit
to shergin/react
that referenced
this pull request
Mar 20, 2017
…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.
sophiebits
pushed a commit
that referenced
this pull request
Mar 21, 2017
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This can happen if something gets unmounted before the event gets
dispatched. I'm not sure how this works out exactly but this
preserves previous behavior in this scenario.