Skip to content

Avoid incrementing the "RT" "last revealed boundary" throttle time when 'revealing' a boundary that is inside a hidden boundary#35777

Draft
rhagigi wants to merge 1 commit intofacebook:mainfrom
rhagigi:Fix-revealing-compelted-boundary-inside-a-hidden-boundary-delaying-the-"RT"-throttle-time

Hidden character warning

The head ref may contain hidden characters: "Fix-revealing-compelted-boundary-inside-a-hidden-boundary-delaying-the-"RT"-throttle-time"
Draft

Avoid incrementing the "RT" "last revealed boundary" throttle time when 'revealing' a boundary that is inside a hidden boundary#35777
rhagigi wants to merge 1 commit intofacebook:mainfrom
rhagigi:Fix-revealing-compelted-boundary-inside-a-hidden-boundary-delaying-the-"RT"-throttle-time

Conversation

@rhagigi
Copy link
Contributor

@rhagigi rhagigi commented Feb 13, 2026

When setting the timeout for revealing completed boundaries, we should not be adding the 300ms throttle for "the last time we revealed a boundary" if the boundary we revealed was just moved inside of a "still suspended" boundary. Using the same logic here as what we do for View Transitions to determine if ParentInstance is a "hidden" boundary to avoid animation.

Summary

How did you test this change?

When setting the timeout for revealing completed boundaries, we should not be adding the 300ms throttle for "the last time we revealed a  boundary" if the boundary we revealed was just moved inside of a "still suspended" boundary. Using the same logic here as what we do for View Transitions to determine if ParentInstance is a "hidden" boundary to avoid animation.
@meta-cla meta-cla bot added the CLA Signed label Feb 13, 2026
continue;
}

const parentRect = parentInstance.getBoundingClientRect();
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we want to check getBoundingClientRect which can call a layout flush. My local fix instead just recurses up the tree and makes sure that the parent chain is mounted in the document and that none of the anchestor has a hidden attribute.

@react-sizebot
Copy link

Comparing: 03ca38e...128f776

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.js = 6.84 kB 6.84 kB +0.11% 1.88 kB 1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js = 611.02 kB 611.02 kB = 108.00 kB 108.00 kB
oss-experimental/react-dom/cjs/react-dom.production.js = 6.84 kB 6.84 kB +0.11% 1.88 kB 1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js = 676.95 kB 676.95 kB = 118.97 kB 118.97 kB
facebook-www/ReactDOM-prod.classic.js = 697.68 kB 697.68 kB = 122.67 kB 122.67 kB
facebook-www/ReactDOM-prod.modern.js = 687.99 kB 687.99 kB = 121.05 kB 121.05 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
oss-experimental/react-dom/unstable_server-external-runtime.js +1.45% 18.15 kB 18.41 kB +1.14% 4.13 kB 4.18 kB

Generated by 🚫 dangerJS against 128f776

@bgirard
Copy link
Contributor

bgirard commented Feb 13, 2026

Here's the demo app that explain the issue more: https://github.com/bgirard/fizz-suspense-demo

In particular read through: https://github.com/bgirard/fizz-suspense-demo/blob/master/src/app/page.tsx

The issue here is we have a hero element. I expect Fizz to show it at 1.8s. But section E incorrectly starts the 300ms delay when it resolves at 1.75s. But Section E is never visible since its parent is still suspended. So starting a delay for this makes no sense.

Screenshot 2026-02-13 at 12 12 35 PM

This is showing up in a production app and causing a 200-300ms delay in some traces.

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.

3 participants