Breadcrumbs Item retains CSS focus styling after focus has passed on to new element

[GrantRussell]

Provide a general summary of the issue here

Breadcrumbs Item retains CSS focus styling even after focus has passed on to a new element.

🤔 Expected Behavior?

Breadcrumb Item should properly remove the blue focus border when it is no longer the focused element in the browser.

😯 Current Behavior

The blue focus border remains around the breadcrumb element.

💁 Possible Solution

N/A

🔦 Context

We are using Breadcrumbs to navigate to a higher-level folder, then pressing tab to start keyboard-navigating the TableView component below the Breadcrumbs.

🖥️ Steps to Reproduce

https://codesandbox.io/s/infallible-flower-x6jmfd?file=/src/App.js

1. Select the Second breadcrumb item with mouse
2. Press tab to start keyboard focus
3. Notice breadcrumb item applies focus CSS even though TableView has the focus
4. Use arrow keys to see that even though the focus has moved to TableView, the CSS blue highlighting remains on the Breadcrumb item.

Version

3.27.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

Windows

🧢 Your Company/Team

Adobe / Assets Essentials

🕷 Tracking Issue

No response

[LFDanLu]

This looks to be due to the removal of the tabIndex when the clicked Breadcrumb becomes the current breadcrumb. If I add autoFocusCurrent to the Breadcrumbs the issue doesn't reproduce because the clicked breadcrumb gets tabIndex=-1 instead of having the tabIndex be removed entirely. Still digging into what in useFocusRing/useFocus is causing the isFocusVisible tracking to break in the first case.

EDIT: Looks to be that focus gets lost to the body when the tabindex gets removed from the new current breadcrumb. React's onBlur doesn't fire when this happens but native onblur does: https://codesandbox.io/s/festive-buck-6nkrjl?file=/src/App.js. Alternatively, perhaps we could dispatch our own blur event like we do for if a button becomes disabled?

[LFDanLu]

This has actually been reported via #2592, #2594 and #2709 have some prior work to fix this case specifically.