Fix: Activity should hide portal contents by acdlite · Pull Request #35091 · react/react

acdlite · 2025-11-10T06:28:08Z

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

acdlite · 2025-11-10T06:28:08Z

Fixes#35000

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it.

Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React.

However, React does own the contents of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle.

The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM.

So, whenever an Activity boundary is hidden, we must search for and hide any portal that is contained within it, and recursively hide its direct children, too.

To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

Matches the pattern we use for the other traversals in the commit phase.

react-sizebot · 2025-11-10T06:32:45Z

Comparing: c83be7d...b748c98

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.68 kB	6.68 kB	+0.11%	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.01%	608.07 kB	608.16 kB	=	107.69 kB	107.64 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.11%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.03%	665.99 kB	666.18 kB	=	117.39 kB	117.35 kB
facebook-www/ReactDOM-prod.classic.js	=	693.36 kB	693.31 kB	=	122.02 kB	121.98 kB
facebook-www/ReactDOM-prod.modern.js	=	683.78 kB	683.73 kB	=	120.40 kB	120.36 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b748c98

rickhanlonii

Looks good, could we add a test? Also seems risky, is it ok to revert if it breaks the sync or could we add a killswitch for the meta builds?

rickhanlonii · 2025-11-10T15:15:44Z

+ return;
+ }
+ case OffscreenComponent:
+ case LegacyHiddenComponent: {


Could we omit LegacyHidden from this? Want to limit the risk of breaking changes and if they need this feature they should convert to Activity.

acdlite · 2025-11-10T15:23:02Z

Yeah I wrote some tests just forgot to stage the file

acdlite · 2025-11-10T15:29:43Z

and yes you can revert if it breaks the Meta sync. Assuming it's due to a bug rather than due to the intentional behavior change. If something is relying on the portal not being hidden then I'd prefer not the revert and we should find some other solution for whatever that code is trying to do. (We could revert with a Meta-only flag in the meantime.)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal. DiffTrain build for [5268492](5268492)

This PR updates the behavior of Activity so that when it is hidden, it hides the contents of any portals contained within it. Previously we had intentionally chosen not to implement this behavior, because it was thought that this concern should be left to the userspace code that manages the portal, e.g. by adding or removing the portal container from the DOM. Depending on the use case for the portal, this is often desirable anyway because the portal container itself is not controlled by React. However, React does own the _contents_ of the portal, and we can hide those elements regardless of what the user chooses to do with the container. This makes the hiding/unhiding behavior of portals with Activity automatic in the majority of cases, and also benefits from aligning the DOM mutations with the rest of the React's commit phase lifecycle. The reason we have to special case this at all is because usually we only hide the direct DOM children of the Activity boundary. There's no reason to go deeper than that, because hiding a parent DOM element effectively hides everything inside of it. Portals are the exception, because they don't exist in the normal DOM hierarchy; we can't assume that just because a portal has a parent in the React tree that it will also have that parent in the actual DOM. So, whenever an Activity boundary is hidden, we must search for and hide _any_ portal that is contained within it, and recursively hide its direct children, too. To optimize this search, we use a new subtree flag, PortalStatic, that is set only on fiber paths that contain a HostPortal. This lets us skip over any subtree that does not contain a portal.

ziyak97 · 2026-01-07T19:13:50Z

Is this already out? Will this fix - vercel/next.js#85502 (reply in thread)

If it’s not out any ETA

abed-daloopa · 2026-06-11T09:37:20Z

When will this be released?

Rewrite hideOrUnhideAllChildren to use recursion
9d8f429
Matches the pattern we use for the other traversals in the commit phase.

meta-claBot added the CLA Signed label Nov 10, 2025

github-actionsBot added the React Core Team Opened by a member of the React Core Team label Nov 10, 2025

acdlite force-pushed the activity-portals-fix branch from b976315 to 17ca31aCompare November 10, 2025 06:28

acdlite marked this pull request as ready for review November 10, 2025 06:33

acdlite requested review from rickhanlonii and sebmarkbage November 10, 2025 06:33

rickhanlonii approved these changes Nov 10, 2025
View reviewed changes

acdlite force-pushed the activity-portals-fix branch from 17ca31a to 58f2ab4Compare November 10, 2025 15:27

acdlite force-pushed the activity-portals-fix branch from 58f2ab4 to f2a23f2Compare November 10, 2025 15:34

acdlite force-pushed the activity-portals-fix branch from f2a23f2 to b748c98Compare November 10, 2025 15:37

acdlite merged commit 5268492 into react:mainNov 10, 2025
239 of 240 checks passed

billyjanitsch mentioned this pull request Nov 10, 2025
Activity mode=“hidden” does not hide nested portals #35000
Closed

nextjs-bot mentioned this pull request Nov 10, 2025
Upgrade React from fa50caf5-20251107 to 52684925-20251110vercel/next.js#85980
Merged

rubennorte mentioned this pull request Jun 5, 2026
Upgrade React and renderers from 19.2.3 to 19.2.7 react/react-native#57089
Closed

atomiks mentioned this pull request Jun 11, 2026
[Combobox] Popup stuck open when combobox unmounts before its close animation completes mui/base-ui#5019
Closed

nwidynski mentioned this pull request Jul 13, 2026
fix: collections in react canary & next 16 app router adobe/react-spectrum#10323
Merged
5 tasks