FloatingFocusManager adds undesirable DOM elements next to the reference element

[mayank99]

When using <FloatingFocusManager modal={false}> (+ <FloatingPortal>), I noticed two sets of extra DOM elements:

1. <span data-type="inside"> (x2) before and after the floating element inside the portal target.
   
2. <span data-type="outside"> (x2) and <span aria-owns="_portal-id_>"> after the reference element.
   

I think I understand 1. It's probably necessary for moving focus back to the reference element when it escapes the floating element. And I'm ok with it, since it is out of the regular document flow.

However, I don't understand the need for 2 (and I couldn't find any documentation). My best guess is that it helps with very complex cases, like comboboxes, where the real focus stays on the reference element and the virtual focus is set using aria-activedescendant. But this is a very niche case; it is far more common for floating elements to be like dialogs, where the DOM focus itself is moved. Would it be possible to disable these extra DOM elements while keeping the modal={false} behavior? These elements are undesirable because they are part of the main document and will break CSS selectors like :nth-child and > * + *.

[atomiks]

This functionality with 4 guards was taken largely from this Sandbox, which allows non-modal focus management to work with React portals across browsers, especially Safari & iOS with VoiceOver which doesn't support aria-owns:

// See Diego Haz's Sandbox for making this logic work well on Safari/iOS:
// https://codesandbox.io/s/tabbable-portal-f4tng?file=/src/FocusTrap.tsx

This was one of the most difficult things to implement and test, and to be honest, I can't really remember how exactly the logic works now lol 😅

The "before" outside guard is used when tabbing from the reference then into the floating element if focus is kept on it when opening the floating element. Regardless of how many focusable elements are between the reference and the portaled floating elements in the DOM tree, focus successfully moves into the floating element, including the virtual cursor with VoiceOver (when not tabbing). Then once focus moves out of the floating element, it moves to the "after" outside guard, which moves focus to the next tabbable element on the document after it. This allows focus to move between the reference and floating element no matter where they lie in the document, including shift+tab, and the VoiceOver virtual cursor going backwards or forwards.

[mayank99]

Thanks for the response! I think this behavior makes sense when there is a need to allow the user to move focus between the reference and the floating element.

However, my floating element grabs focus when opened, and it closes when focus leaves (and causes focus to move to the reference if shift+tab or the element after the reference if tab). I think it should be possible to avoid these guards in such cases, no? This could even be done automatically based on the order specified in FloatingFocusManager.

Additionally, I think some documentation around this would be useful (I can try to submit a PR).

[atomiks]

That doesn't work in Safari using VoiceOver, especially iOS where there's no ability to tab. If they swipe backwards, and end up on the reference element (which doesn't close the floating element), swiping forwards needs to move focus back into the floating element which requires focus to hit the focus guard to move; you can't listen for keydown and the Tab key, etc.