fix(useGridState): prevent infinite loop restoring focus when no focusable row remains

[RobHannay]

Description

useGridState's focus-restoration effect (which runs when the focused row is removed from the collection) searches collection.rows for a non-disabled, non-headerrow row to move focus to. It's meant to scan forward from the deleted position to the end, then fall back to scanning backward — but the forward/backward handoff is broken:

while (index >= 0) {
  if (!selectionManager.isDisabled(rows[index].key) && rows[index].type !== 'headerrow') {
    newRow = rows[index];
    break;
  }
  if (index < rows.length - 1) {
    index++;                                  // forward
  } else {
    if (index > parentNode.index) index = parentNode.index;
    index--;                                  // "backward"
  }
}

After the forward pass reaches the end and resets to parentNode.index / decrements, the next iteration's index < rows.length - 1 check sends it forward again. So when no focusable row remains (every row in range is disabled or a headerrow), index bounces between parentNode.index and the end and never reaches index < 0 — an infinite loop that hangs the main thread.

This is reachable whenever the focused row is removed and the new collection has no focusable row — e.g. a table whose rows are momentarily all-disabled loading skeletons while a row was focused. In our app it hard-froze the browser tab on filter/search/tab changes (Firefox "page is slowing down", Chrome unresponsive), independent of row count.

Fix

Replace the single bouncing loop with two bounded passes — forward from the start index, then backward — mirroring the already-correct walk in useListState (getKeyAfter/getKeyBefore). Math.max(0, index) keeps an empty rows array (index === -1) from reading rows[-1], matching the old while (index >= 0) no-op.

Only useGridState is affected; useListState and useTreeState already handle this case safely.

How I tested

Added a regression test in react-aria-components/test/Table.test.js: focus a row, then re-render with that row removed and every remaining row disabled.

• Verified that without the fix, the new test hangs indefinitely — the infinite loop blocks the main thread so jest never completes (had to kill it).
• With the fix it passes (~35 ms): focus is cleared and the render completes.
• The existing supports removing rows test still passes, so focus restoration on normal removal is unchanged.

🧢 Your Project

react-aria-components / @react-stately/grid (Table)

[RobHannay]

Real-world signal in support of this: we've been running this exact change as a patch (pnpm patch on react-stately@3.48.0, mirroring the diff here) in our production app since yesterday.

The bug was hard-freezing browser tabs for users on our Table-based screen — a focused row plus a refetch that briefly swapped in an all-disabled (loading-skeleton) collection sent the focus-restoration loop bouncing forever. Since deploying the double-walk fix (forward then backward, ~24h ago), we've had zero recurrences on that surface, where it had been a recurring report.

So in addition to the regression test, it's holding up under real traffic. Happy to provide anything else that helps review.

[snowystinger]

Looks good, two minor comments