fix(useSelectableCollection): focus previous tab stop on Shift+Tab instead of collection root

[coolassassin]

Summary

When Shift+Tab is pressed inside a collection with allowsTabNavigation={false} (Table, ListBox, GridList, etc.), useSelectableCollection called ref.current.focus() on the collection root before the browser continued tabbing. That intermediate focus on the grid root is an unnecessary pivot — focus should move directly to the previous tab stop outside the collection.

For RAC Table this caused extra focus transitions and downstream React re-renders (for example Row useFocusRing({ within: true }) when focus briefly lands on the grid root).

The fix mirrors the forward-Tab branch: on Shift+Tab, when the previous external tab stop matches the collection boundary, we preventDefault and focusWithoutScrolling that element. Otherwise we fall back to collectionRoot.focus() (nested collections, mobile submenu back button, etc.).

Changed files:

• packages/react-aria/src/selection/useSelectableCollection.ts
• packages/react-aria/test/selection/useSelectableCollection.test.js
• packages/@adobe/react-spectrum/test/table/TableTests.js

Guards:

• prev === prevFromRoot — direct exit only from the collection boundary as a single tab stop
• prev must not belong to another [data-collection] outside the current root
• tab stops in the same menu [role="dialog"] but outside the collection use the fallback path
• no stopPropagation() (ComboBox dev-mode)

✅ Pull Request Checklist:

• Connected with this issue
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component). — N/A, behavior-only fix.
• Looked at the Accessibility Practices for this feature - Aria Practices — Grid and Table Keyboard Interaction: Tab / Shift+Tab should move focus into/out of the grid without trapping on the grid container.

📝 Test Instructions:

Automated

yarn jest packages/react-aria/test/selection/useSelectableCollection.test.js -t "shift+tabs"
yarn jest packages/@adobe/react-spectrum/test/table/Table.test.js -t "should move focus before the table when shift tabbing"
yarn jest packages/@adobe/react-spectrum/test/combobox/ComboBox.test.js -t "tab and shift tab"
yarn jest packages/@adobe/react-spectrum/test/menu/SubMenuTrigger.test.tsx
yarn jest packages/react-aria-components/test/Tree.test.tsx -t "should focus the dropped row when dropped on a parent that is expanded"

The new test uses fireEvent.keyDown (not user.tab({ shift: true })) so it exercises useSelectableCollection's Tab handler — same caveat as GridList.test.js.

Manual (Table / Storybook)

1. Place a focusable element before a Table (e.g. a button).
2. Tab into the table, focus a cell or an internal control (switch, button).
3. Shift+Tab back to the button.
4. Confirm focus lands on the button without flashing focus on the table grid root.
5. Optional: in React DevTools Profiler, confirm fewer cell re-renders on Shift+Tab vs. before.

Regression

• Tab into a collection still works.
• Tab out (forward) is unchanged.
• Shift+Tab between items inside a collection still works.

🧢 Your Project:

dxFeed (Devexperts) — internal Table built on react-aria-components (Table, div-grid, focusMode="cell").

[snowystinger]

Thanks for the interest, as you can see, there's a bit of complexity with moving focus ourselves. It'd be better if we can let the browser handle the focus movement. This will help it work with things like shadow dom and iframes.

The approach I'd look into would be to solve the re-renders by reducing the props or context that change for the cells. Did you try something like that and run into problems?

Can you submit an issue with reproduction instructions?

[coolassassin]

@snowystinger Did the issue with details:
#10254

From my perspective, the main issue is that the table collection lives in React and works with React components. If there were an option to provide a table model to the table as a data structure, it would be possible to build a much more efficient solution for data grids.

On the other hand, the current table solution updates the entire state on any change by design. If there were a way to update only the necessary parts of the state, it would be much more performant even with the current approach, but that would require a fairly significant change and refactoring. So, this PR is just a small fix for a local issue, trying to keep everything as is.

[snowystinger]

I see, but it doesn't keep everything "as is". There are multiple cases this would now break as I pointed out previously.

We should try turning on the React Compiler, that may reduce the number of re-renders we see without needing to do anything.

Another thing we could try is, we know that during shift+tab, when we move focus to the collection root, we're also going to immediately lose it, so we could try to skip the focus ring updates there.

Another approach could be to use useSyncExternalStore instead of the context, then only subscribe the row or cells that need to be updated.

[coolassassin]

@snowystinger
I think that the React compiler is not a silver bullet and is unlikely to fix context issues. Maybe only hide some of them.
For me, RC is kinda app level solution, not a library method to solve performance issues.

About the current solution, am I right that it is not what you as a team want to see in your code base? I mean, if I want to fix it, I have to find a better solution?

[coolassassin]

@snowystinger
I did an alternative version of the fix:
#10283

It is less efficient (fix all rows that are not focused), but it has a significant impact as well

[snowystinger]

I think that the React compiler is not a silver bullet and is unlikely to fix context issues. Maybe only hide some of them.
For me, RC is kinda app level solution, not a library method to solve performance issues.

No, I wouldn't expect it to be a silver bullet, but it might eliminate enough unstable things that it is "good enough". At the very least it'd get rid of some noise.

Once the rest of the team is back from break I will ask.