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.