-
Notifications
You must be signed in to change notification settings - Fork 48.8k
[Bugfix] Incorrect return pointer on deleted fiber #20942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1964,6 +1964,10 @@ function commitMutationEffects_begin( | |
if (deletions !== null) { | ||
for (let i = 0; i < deletions.length; i++) { | ||
const childToDelete = deletions[i]; | ||
// When deleting a host node, we follow the return path to find the | ||
// neartest mounted host parent. Which means the return pointer of | ||
// the deleted tree must be correct. | ||
childToDelete.return = fiber; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In my testing, the I'm wondering if the repro I had (the larger one that involved Feed and was more touch and go) is a different problem. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It’s always non-null at this particular location, but before the fix it would sometimes point to the wrong alternate. Does that describe what you were seeing? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, pretty sure I was seeing a double deletion, and the pointer was cleared in detach mutation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right, I checked again and it was a double deletion. Fix here: #20942 |
||
if (__DEV__) { | ||
invokeGuardedCallback( | ||
null, | ||
|
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of doing that on-demand, we could do that eagerly here and then pass in the parent.
It's likely to be at least one DOM node deleted. If it's more than one, then it's unnecessary to backtrack more than once. We meant to do that optimization for that reason at some point anyway.
Or better yet, keep track of it on the stack since we're traversing through the parent anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use recursion for this function yet (was reverted because of slow down in open source build) so it'd have to be a virtual stack.
So I'll go with option 1 (eagerly find the current parent) for now and leave a TODO for when this recursive traversal is converted to use the JS stack.