Skip to content
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

Fix Ref Lifecycles in Hidden Subtrees #31379

Merged
merged 10 commits into from
Oct 31, 2024

Conversation

yungsters
Copy link
Contributor

@yungsters yungsters commented Oct 28, 2024

Summary

We're seeing certain situations in React Native development where ref callbacks in <Activity mode="hidden"> are sometimes invoked exactly once with null without ever being called with a "current" value.

This violates the contract for refs because refs are expected to always attach before detach (and to always eventually detach after attach). This is particularly bad for refs that return cleanup functions, because refs that return cleanup functions expect to never be invoked with null. This bug causes such refs to be invoked with null (because since safelyAttachRef was never called, safelyDetachRef thinks the ref does not return a cleanup function and invokes it with null).

This fix makes use of offscreenSubtreeWasHidden in commitDeletionEffectsOnFiber, similar to how ec52a56 did this for commitDeletionEffectsOnFiber.

How did you test this change?

We were able to isolate the repro steps to isolate the React Native experimental changes. However, the repro steps depend on Fast Refresh.

function callbackRef(current) {
  // Called once with `current` as null, upon triggering Fast Refresh.
}

<Activity mode="hidden">
  <View ref={callbackRef} />;
</Activity>

Ideally, we would have a unit test that verifies this behavior without Fast Refresh. (We have evidence that this bug occurs without Fast Refresh in real product implementations. However, we have not successfully deduced the root cause, yet.)

This PR currently includes a unit test that reproduces the Fast Refresh scenario, which is also demonstrated in this CodeSandbox: https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7

Verified unit tests pass:

$ yarn
$ yarn test
# Run with `-r=www-classic` for `enableScopeAPI` tests.
$ yarn test -r=www-classic

Verified on the internal React Native development branch that the bug no longer repros.

Copy link

vercel bot commented Oct 28, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-compiler-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 30, 2024 9:23pm

@react-sizebot
Copy link

react-sizebot commented Oct 28, 2024

The size diff is too large to display in a single comment. The GitHub action for this pull request contains an artifact called 'sizebot-message.md' with the full message.

Generated by 🚫 dangerJS against 82bea69

@yungsters
Copy link
Contributor Author

By the way, I don't add these checks to the safelyDetachRef calls in disappearLayoutEffects because recursivelyTraverseDisappearLayoutEffects (which calls disappearLayoutEffects) already checks for offscreenSubtreeWasHidden on Line 2017.

@@ -2073,7 +2077,7 @@ function commitMutationEffectsOnFiber(

// TODO: This is a temporary solution that allowed us to transition away
// from React Flare on www.
if (flags & Ref) {
if (flags & Ref && !offscreenSubtreeWasHidden) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem clear to me if the safelyAttachRef call should be done conditional here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually, it makes sense to skip both. I'm not sure why Scope refs are even being attached here in the first place. 😕

@sammy-SC
Copy link
Contributor

I believe this is a good approach to fix it.

Could you explain in the PR description why offscreenSubtreeWasHidden is the right choice here?

@yungsters
Copy link
Contributor Author

I believe this is a good approach to fix it.

Could you explain in the PR description why offscreenSubtreeWasHidden is the right choice here?

@sammy-SC Added this to the PR summary:

This fix makes use of offscreenSubtreeWasHidden in commitDeletionEffectsOnFiber, similar to how ec52a56 did this for commitDeletionEffectsOnFiber.

@@ -1744,7 +1748,7 @@ function commitMutationEffectsOnFiber(
recursivelyTraverseMutationEffects(root, finishedWork, lanes);
commitReconciliationEffects(finishedWork);

if (flags & Ref) {
if (flags & Ref && !offscreenSubtreeWasHidden) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the Jest unit test that @rickhanlonii added in a2c9e7a, this is the only line that is actually necessary to fix the unit test.

Comment on lines +2081 to +2086
if (!offscreenSubtreeWasHidden && current !== null) {
safelyDetachRef(finishedWork, finishedWork.return);
}
safelyAttachRef(finishedWork, finishedWork.return);
if (!offscreenSubtreeIsHidden) {
safelyAttachRef(finishedWork, finishedWork.return);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kassens, I think this is the correct behavior.

You were right that !offscreenSubtreeWasHidden should only be scoped to safelyDetachRef, and we were missing a !offscreenSubtreeIsHidden check around safelyAttachRef.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure about this behavior? We don't check for Offscreen anywhere else that we attach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't check for Offscreen anywhere else that we attach.

We actually do, but it's implicit.

Every other type calls safelyAttachRef from reappearLayoutEffects, which is called only by recursivelyTraverseReappearLayoutEffects. These occur during:

In both of these, we prune traversal when we encounter a hidden Offscreen. (See the links above for where this happens.)

Are you sure about this behavior?

I'm not sure why ScopeComponent requires safelyAttachRef to be here, but I assume it has something to do with the comment above:

// TODO: This is a temporary solution that allowed us to transition away
// from React Flare on www.

I don't plan to change this as part of fixing refs, though. I considered an alternative in which I leave ScopeComponent alone, but I think this is actually the correct fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why ScopeComponent requires safelyAttachRef to be here, [...]

I traced the origin of that comment (which was harder than I expected due to the reconciler forking and unforking that happened) and found this: #19264

To unblock internal progression on replacing React Flare, let's instead move resolution of Scope API refs to the mutation phase, so we can attach event listeners to scopes before the layout phase begins.

I don't fully understand the context, but I figured that it would be helpful to know its origin.

Copy link
Contributor Author

@yungsters yungsters Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

~~After writing unit tests for this bug, I've confirmed that these changes are actually not needed to prevent <Scope ref={X}> from invoking X in <Activity mode="hidden">.

I've dropped these changes for now.~~

Oh… just kidding, I was not running yarn test with -r=www-classic (which is where enableScopeAPI is enabled). These changes are needed after all, will update.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirmed that Scope was previously completely ignoring any parent Activity that declared the subtree as hidden.

Comment on lines +1340 to +1342
if (!offscreenSubtreeWasHidden) {
safelyDetachRef(deletedFiber, nearestMountedAncestor);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the unit test for "ignores ref for Activity in hidden subtree", I discovered that this and the call from commitMutationEffectsOnFiber are triggered, causing X to be incorrectly invoked twice! 🤯

<Activity mode="hidden">
  <Activity mode="visible" ref={X}>
    <div />
  </Activity>
</Activity>

@yungsters
Copy link
Contributor Author

I've expanded on the unit tests and verified that 1) each new test fails without this PR, and 2) each line modified by this PR (except for that one comment misspelling) is necessary for one of the new tests to succeed.

@yungsters yungsters changed the title Avoid Detaching Refs on Hidden Subtrees Fix Ref Lifecycles in Hidden Subtrees Oct 31, 2024
@yungsters yungsters merged commit ea3ac58 into facebook:main Oct 31, 2024
184 checks passed
@yungsters yungsters deleted the hidden-detach-refs branch October 31, 2024 20:25
github-actions bot pushed a commit that referenced this pull request Oct 31, 2024
## Summary

We're seeing certain situations in React Native development where ref
callbacks in `<Activity mode="hidden">` are sometimes invoked exactly
once with `null` without ever being called with a "current" value.

This violates the contract for refs because refs are expected to always
attach before detach (and to always eventually detach after attach).
This is *particularly* bad for refs that return cleanup functions,
because refs that return cleanup functions expect to never be invoked
with `null`. This bug causes such refs to be invoked with `null`
(because since `safelyAttachRef` was never called, `safelyDetachRef`
thinks the ref does not return a cleanup function and invokes it with
`null`).

This fix makes use of `offscreenSubtreeWasHidden` in
`commitDeletionEffectsOnFiber`, similar to how
ec52a56
did this for `commitDeletionEffectsOnFiber`.

## How did you test this change?

We were able to isolate the repro steps to isolate the React Native
experimental changes. However, the repro steps depend on Fast Refresh.

```
function callbackRef(current) {
  // Called once with `current` as null, upon triggering Fast Refresh.
}

<Activity mode="hidden">
  <View ref={callbackRef} />;
</Activity>
```

Ideally, we would have a unit test that verifies this behavior without
Fast Refresh. (We have evidence that this bug occurs without Fast
Refresh in real product implementations. However, we have not
successfully deduced the root cause, yet.)

This PR currently includes a unit test that reproduces the Fast Refresh
scenario, which is also demonstrated in this CodeSandbox:
https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7

Verified unit tests pass:

```
$ yarn
$ yarn test
# Run with `-r=www-classic` for `enableScopeAPI` tests.
$ yarn test -r=www-classic
```

Verified on the internal React Native development branch that the bug no
longer repros.

---------

Co-authored-by: Rick Hanlon <rickhanlonii@fb.com>

DiffTrain build for [ea3ac58](ea3ac58)
github-actions bot pushed a commit that referenced this pull request Oct 31, 2024
## Summary

We're seeing certain situations in React Native development where ref
callbacks in `<Activity mode="hidden">` are sometimes invoked exactly
once with `null` without ever being called with a "current" value.

This violates the contract for refs because refs are expected to always
attach before detach (and to always eventually detach after attach).
This is *particularly* bad for refs that return cleanup functions,
because refs that return cleanup functions expect to never be invoked
with `null`. This bug causes such refs to be invoked with `null`
(because since `safelyAttachRef` was never called, `safelyDetachRef`
thinks the ref does not return a cleanup function and invokes it with
`null`).

This fix makes use of `offscreenSubtreeWasHidden` in
`commitDeletionEffectsOnFiber`, similar to how
ec52a56
did this for `commitDeletionEffectsOnFiber`.

## How did you test this change?

We were able to isolate the repro steps to isolate the React Native
experimental changes. However, the repro steps depend on Fast Refresh.

```
function callbackRef(current) {
  // Called once with `current` as null, upon triggering Fast Refresh.
}

<Activity mode="hidden">
  <View ref={callbackRef} />;
</Activity>
```

Ideally, we would have a unit test that verifies this behavior without
Fast Refresh. (We have evidence that this bug occurs without Fast
Refresh in real product implementations. However, we have not
successfully deduced the root cause, yet.)

This PR currently includes a unit test that reproduces the Fast Refresh
scenario, which is also demonstrated in this CodeSandbox:
https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7

Verified unit tests pass:

```
$ yarn
$ yarn test
# Run with `-r=www-classic` for `enableScopeAPI` tests.
$ yarn test -r=www-classic
```

Verified on the internal React Native development branch that the bug no
longer repros.

---------

Co-authored-by: Rick Hanlon <rickhanlonii@fb.com>

DiffTrain build for [ea3ac58](ea3ac58)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants