RAC Tabs/useFocusWithin crashes with `Failed to execute contains on Node` on a Tabs-wrapped page with portal-based date/select controls

[luisrudge]

We are seeing a runtime crash in React Aria Components on a page wrapped in Tabs.

The page contains portal-based date/select controls. After interacting with those controls and then clicking a submit button, the app throws:

Uncaught TypeError: Failed to execute 'contains' on 'Node': parameter 1 is not of type 'Node'.

We only see this when the page is wrapped in react-aria-components Tabs. The same schedule UI flow works on a page that is not wrapped in Tabs.

Expected Behavior?

No crash during focus/blur handling.

Current Behavior

The app crashes in useFocusWithin / nodeContains.

Stack:

Uncaught TypeError: Failed to execute 'contains' on 'Node': parameter 1 is not of type 'Node'.
    at $d4ee10de306f2510$export$4282f70798064fe0 (react-aria-components.js?v=3fd722a5:230:84)
    at react-aria-components.js?v=3fd722a5:6471:8
    ...

Relevant bundled code:

function nodeContains(node, otherNode) {
  if (!shadowDOMEnabled) {
    return otherNode && node ? node.contains(otherNode) : false;
  }
  ...
}

and:

if (!nodeContains(e.currentTarget, getEventTarget(e))) return;

Context

We are not using Shadow DOM.

Observed behavior in our app:

• page rendered inside react-aria-components Tabs → crash
• same page content rendered outside Tabs → no crash

This suggests the issue is related to focus handling introduced by Tabs / useFocusWithin, but we do not yet have a minimal standalone reproduction.

Version

react-aria-components: 1.16.0
react-aria: 3.47.0
@react-aria/utils: 3.33.1

What browsers are you seeing the problem on?

Chrome

What operating system are you using?

macOS

Related upstream work

Possibly related:

• RAC Menu not able to click menu items when using UNSAFE_PortalProvider in a web component #8675
• fix: all node.contains for shadow dom usage #9485
• fix: all event target for shadow dom #9551

Question

Is this a known scenario where the fallback non-shadow-DOM nodeContains path still needs to guard against non-Node values?

[snowystinger]

Thanks for the issue. I'm having trouble figuring out what your setup is. Particularly "The page contains portal-based date/select controls. After interacting with those controls and then clicking a submit button, the app throws:"

Even if you don't have a minimal reproduction yet, maybe an example showing the key pieces would be helpful.

If it's not a Node, what is it? And what does the submit button do? Does it change the Tab?

[luisrudge]

as you can imagine, AI wrote the entire issue description 😅 but I spent quite some time figuring it out what was going on to make sure the details were accurate. From now on, it's gonna be me (unless I need to create a repro).

This issue happens because I have an old material-ui component inside a react-aria-component tabs. The component is a @material-ui/core/Select with multiple @material-ui/core/MenuItem options ("@material-ui/core": "^4.10.2").
It's something like

<tabs>
  <tablist>.....</tablist>
  <tabpanel>
     <form>
         <MUISelect>
              <MUIMenuItem />
              <MUIMenuItem />
              <MUIMenuItem />
              <MUIMenuItem />
         </MUISelect>
         <submitbtn/>
     </form>
  </tabpanel>
</tabs>

when you submit the form, we redirect to another page (react router's navigate). I can see the error in the console, but because react router already sent the navigate request, the page still navigates, but cypress e2e test fails because of the unhandled error. I'm currently ignoring this error so the tests pass, however this error still gets reported in our error tracking so that's not ideal. If you can think of something that might be causing this or how to fix it in the RAC codebase, great. If not, I'll see if I can create a repro.

The offending line is here https://github.com/adobe/react-spectrum/blob/main/packages/react-aria/src/utils/shadowdom/DOMFunctions.ts#L16. A try/catch would address this issue, but not sure you'd want to swallow these errors...

[snowystinger]

Haha, no worries. Though it's pretty hard to look into the implementation of the MUI component as that 4+ year old code. So what is the node that it's trying to check? is it just undefined?
It looks like useFocusWithin is only used in

react-spectrum/packages/react-aria-components/src/Tabs.tsx

Line 199 in bef549d

let {focusProps, isFocused, isFocusVisible} = useFocusRing({within: true});

Which shouldn't have focus while you're interacting with a Select nor the Submit button. If it was an issue with blur, I'd have expected it to happen earlier since it sounds like there is a two step interactions process, first the Select, then the Button to submit. So it would probably be an issue with focusing the tab. Can you think of a reason that the tab or something inside the tab (not the tab panel) would be focused in your case?

[luisrudge]

Very interesting.. e.target is an object 🤔

I tested it again and it does happen without a redirect as well. If I have two selects on the page it does the same thing.

[snowystinger]

Apologies, but for some reason I cannot see the image, it's displaying a broken link. Maybe try attaching it again? I've seen this happen a few times recently, so could be a problem with Github as well.

e.target is an object what kind of object is it representing? does it have a type field or anything to give us a clue?

[luisrudge]

can you see it now? it's a javascript object {name: undefined, value: 120}

[snowystinger]

So it looks like this is the reason for that non-Node type https://github.com/mui/material-ui/blob/d0bfcb4f11fd3904b1e235d80fbfe23758de8372/packages/material-ui/src/Select/SelectInput.js#L224
Do you have a name attribute/prop on your select? if you do, does it show there?

I would say this is something they shouldn't be doing, if you can, I'd suggest upgrading to a newer version or to our Select.

Otherwise you can patch either library however you think you'd like to handle it best. But this doesn't seem like a "real" case, so I'd prefer not to change our implementation which would have unknown consequences without a lot more thought.

[luisrudge]

Yeah I understand your POV. I'll use a patch! Thank you