react-spectrum: @react-aria/focus - Failed to execute 'createTreeWalker' on 'Document'

🐛 Bug Report

It is a bug similar to https://github.com/adobe/react-spectrum/issues/4407 but there are some differences, which is why I decided to create a separate report.

When executing both component and e2e Cypress tests, sometimes after the modal is closed, an error Failed to execute 'createTreeWalker' on 'Document': parameter 1 is not of type 'Node'. pops up. I checked in on older versions of the library and the issue was already there. Also, I wrote Cypress tests using react-aria-components and the result was the same.

🤔 Expected Behavior

No error should be thrown.

😯 Current Behavior

The error is thrown when any element inside the modal FocusScope is focused, and the modal is closed by clicking on the button closing the modal. This part of the code executes when FocusScope is already unmounted and an error is thrown.

💁 Possible Solution

I saw this commit that could possibly solve the issue. Don’t know why it was removed though.

🔦 Context

I’m testing the behavior of the modal implemented with the usage of react-aria. ~10% of test runs fail because of this issue on Chrome, on Firefox it is around 40%.

💻 Code Sample

I can’t provide an exact sample but a really simple example behaves exactly the same. autoFocus isn’t necessary - focusing input in the test also works, it just makes the test simpler.

const Example: VFC = () => {
  const modalState = useOverlayTriggerState({});

  return (
    <>
      <button onClick={modalState.open} data-qa="open">Open modal</button>
      {modalState.isOpen && (
        <div>
          <FocusScope restoreFocus contain autoFocus>
            <input type="text"/>
            <button onClick={modalState.close}/>
          </FocusScope>
        </div>  
      )}
    </>
  );
};

Test:

describe("Error example", () => {
  Cypress._.times(100, () => {
    it("", () => {
      mount(<Example/>);
      cy.get("#open").should("be.visible").realClick();
      cy.get("#close").should("be.visible").realClick();
    });
  });
});

🌍 Your Environment

Library: “@react-aria/focus”: “3.12.0”. React: 17.0.2 Cypress: 12.8.1 OS: Windows 10

About this issue

Original URL
State: closed
Created a year ago
Comments: 20 (10 by maintainers)

Most upvoted comments

Ah, yep, that’s Spectrum specific. So yeah, you’ll just want to handle it outside of the Item, as far up as makes sense

snowystinger on Sep 26, 2023

Oo, this is fantastic news then. I’ll have my teammates try it and see if any of us can debug a little more

snowystinger on Sep 25, 2023

Hi,

Thank you so much for looking into this 🙏 . I was quickly checking the repro that you put together, convinced that it would not show the issue as you said. Though, surprisingly I was able to reproduce 😅 . It does not seems to occur all the time but it does show up quite a lot.

It does seem that changing the onDelete function to use a function instead of updated state directly, makes the issue go away. The behaviour is also different. I’m not sure if it was set up like this on purpose?

let onDelete = (key) => {
    setItems((items) => items.filter((item) => item.key !== key));
  };

test

Tested on Chrome Version 116.0.5845.187

To answer your questions:

The <Item> component seems to be pretty similar to what you have put together in the repro. Not much special going on in there. We are using React Aria hooks though… I’ll try wrapping it with FocusScope and report back!
Yes, there are delays at play in our case. Whenever the user presses the confirmation button in the modal we will fire a graphql mutation and wait for this the resolve. As a result of said mutation, the list of items will be refresh and the <Item> will no longer be there.

skrivle on Sep 25, 2023

Hi @LFDanLu , after some delays I was able to determine what was happening in our code base. I looks like we had a race condition with deleting and refreshing our components. After clicking the primary button on a dialog to delete an item from our list, our components were not blocking while that delete was happening so they were re-rendering immediately. Once I added the check to wait for deletion to complete we never saw the crash again. These components are wrapped in a series of context’s to share state across components which made it a little tricky to debug at first. At this point we are happy with our current solution. Thanks for all the suggestions and point me in the right direction.

bsramming on Aug 2, 2023

Thanks @LFDanLu! Really appreciate the responses. I’m starting to peal back the different layers and reduce the code to the bare minimum and see what custom settings we have that would be impacting this. It’s a bit tedious 😃 Will share any breakthroughs when I come across them. To answer your questions:

We do have react StrictMode enabled. I did a quick test and turned it off. Still see the crash.
We do have some custom implementations around Dialog/DialogContainter, but my recent tests and debug have been with those removed. There might still be more hidden ones that I’m looking into as I peel back the different components.
Versions:

React = 18.2
react-spectrum = 3.21.0
Lot of spectrum-css

I hope to get the code into a rough sandbox state to be able to share. Might take some time unfortunately 😦
Yep confirmed in debugger that both breakpoints are referencing the same scopeRef

Totally understand wanting to get to the bottom of this and root cause the issue

bsramming on Jul 19, 2023

@snowystinger I also saw this issue when I upgraded my @react-aria/focus to ^3.12.0

amrmetwalyy on Jun 20, 2023