[devtools]: Prevent false positive render detection in profiler (#33423, #19732)

[developerjhp]

Summary

Fixes a bug in React DevTools where the profiler incorrectly reported sibling components as re-rendered when they were nested under HostComponents (like <div>) that get filtered out by DevTools. This affected profiler data collection, render highlighting, and inspector cache management.

Background

React DevTools filters out DOM elements (HostComponents) by default to focus on user components. However, this filtering created a blind spot where sibling components under the same HostComponent parent would be incorrectly reported as re-rendered even when their Fiber objects remained identical.
This is a follow-up to #33434

Previous Attempt & Learning

#33434 helped identify that the issue wasn't with didFiberRender logic itself, but with when it was being called. The filtering behavior provided the key insight that components with identical Fiber objects shouldn't trigger render
detection when their parent HostComponents are filtered.

Example scenario:

const Count = () => {
  const [count, setCount] = useState(0);
  console.log('Count Component Rerendered');
  return (
      <button onClick={() => setCount(c => c + 1)}>
          Count: {count}
      </button>
  );
};

const Greeting = () => {
  console.log('Greeting Component Rerendered');
  return <span>Hello World!</span>;
};

const App = () => {
  const [appState, setAppState] = useState(0);
  console.log('App Component Rerendered');
  
  return (
      <main>
          <div>App State: {appState}</div>
          <button onClick={() => setAppState(s => s + 1)}>
              App Rerender Trigger (All children rerender)
          </button>
          <hr />
          <Count />
          <div>
              <Greeting />
          </div>
      </main>
  );
};

Root Cause

The issue occurred because didFiberRender was being called for components whose Fiber objects remained referentially identical (prevFiber === nextFiber) but were nested under HostComponents. When the parent HostComponent processed its children during reconciliation, DevTools would check all child components without recognizing that some hadn't actually re-rendered.

Key insight

If prevFiber === nextFiber and the parent is a filtered HostComponent, then didFiberRender shouldn't be called at all - not because the function is wrong, but because the component genuinely hasn't re-rendered.

Solution

Instead of modifying didFiberRender logic, this fix prevents the function from being called when we can objectively determine a component hasn't re-rendered. The fix adds conditional checks in three critical locations:

1. Profiler Data Collection (renderer.js:2816)

• Prevents false positive entries in profiler commit data when components haven't actually re-rendered.

2. Render Highlighting (renderer.js:3327)

• Prevents incorrect highlighting of components during trace updates when they haven't changed.

3. Inspector Cache Management (renderer.js:3359)

• Preserves cached inspection data when components haven't actually re-rendered, avoiding unnecessary re-computation.

Implementation Details

The fix uses objective criteria to detect when didFiberRender shouldn't be called:

  if (
    prevFiber === nextFiber &&  // Same Fiber object reference
    nextFiber.return != null &&
    (nextFiber.return.tag === HostComponent || nextFiber.return.tag === HostSingleton)  // Parent is filtered HostComponent
  ) {
    // Don't call didFiberRender - component hasn't actually re-rendered
  }

This approach:

• Addresses false positives at the source
• Maintains existing didFiberRender logic unchanged
• Applies consistently across all DevTools features
• Uses objective, verifiable criteria
• No performance impact on normal rendering

Related Issues

Fixes #33423, #19732

[developerjhp]

@hoxyq

I've implemented a fix for the false positive render detection issue we discussed in #33423.

The solution prevents calling didFiberRender when prevFiber === nextFiber and the parent is a HostComponent/HostSingleton, which addresses the filtering issue you mentioned. I've added conditional checks in three locations:

1. Profiler data collection
2. Render highlighting
3. Inspector cache management

I've tested this manually with the Chrome extension and confirmed it fixes both the profiler data and highlighting issues. Would you mind taking a look when you have a chance?

Thanks for the guidance on the root cause - it really helped narrow down the solution! 🙏