1.7.12 `inert` change on root element breaks Dialog sidebar use cases

[samesfahani-tuplehealth]

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

For example: v1.7.11

What browser are you using?

Chrome

Reproduction URL

Working example: https://stackblitz.com/edit/vitejs-vite-fpxdgf?file=package.json
Broken example: https://stackblitz.com/edit/vitejs-vite-ldjlty?file=package.json

The only difference between the two are @headlessui/react versions.

Describe your issue

We have a unique use case where we want to display a modal on top of the main app section while allowing our sidebar sections to be interactive. In fact this was one of the main reasons we even opted to use headlessui in the first place since it would allow for these customizations.

#2290 has broken that assumption since it marks the root element inert, which is not what we want.

1.7.11 DOM

1.7.12 DOM

I realize this probably isn't the most common use case, but I need a way to opt out. Could this be fine tuned via a prop?

[RobinMalfait]

Hey, thank you for this bug report! 🙏

The inert attribute should have always been there but it wasn't so we fixed that. The reason behind this is that the moment you have a Dialog component, then all other components on the page should not be interactable. The inert property itself is relatively new (if you use the native dialog component you also get this behaviour).

Now, this of course doesn't solve your issue, but there is a solution to this problem. If you want to be able to interact with anything while the Dialog component is open, you should put those elements inside the Dialog component.

Here is an updated StackBlitz link where I moved the sidebar inside of the Dialog component. I also added some input fields to demonstrate that you can now use tab and shift+tab to interact with all input fields.
Updated link: https://stackblitz.com/edit/vitejs-vite-hxghnw?file=src%2FApp.tsx

Hopefully this helps!

[samesfahani-tuplehealth]

I guess I do understand that everything works when inside of a dialog, but the problem is the sidebar is meant to be an app-wide sidebar that is meant to persist with or without a dialog open, so that solution doesn't really work for me.

[samesfahani-tuplehealth]

const root = document.getElementById('root');
root.removeAttribute('inert');
root.removeAttribute('aria-hidden');

This code block in a useEffect would restore the behavior. It's ugly of course and can have potential side-effects.

[paul-cho-39]

@samesfahani-tuplehealth, useEffect would not restore the behavior, at least in Next.js application. I'm not 100% sure of this, but I think the inert is a global handler or context provider, so it will override the useEffect. If you want to render the Dialog component and intend to use it as an app-wide sidebar, you can try using Portal. When rendered inside the portal, it won't be affected by the parent container and the Portal parent container will have the attribute inert.

Using Next.js application: "

   const [root, setRoot] = useState<HTMLElement | null>(null);
   useEffect(() => {
      setRoot(document.getElementById('sidebar-root'));
   }, []);

   if (!root) return null;

// the SideNavigation is the dialog component to be rendered not in the parent container
   return ReactDOM.createPortal(
      <SideNavigation sidebarOpen={sidebarOpen} setSidebarOpen={setSidebarOpen}>
         {/* Modal content */}
      </SideNavigation>,
      root
   );
};

[michealroberts]

@samesfahani-tuplehealth I think the takeaway is that a element should always mark the root node as inert as per the specification. Your usage isn't therefore semantically correct.

[OgLuka]

@samesfahani-tuplehealth, useEffect would not restore the behavior, at least in Next.js application. I'm not 100% sure of this, but I think the inert is a global handler or context provider, so it will override the useEffect. If you want to render the Dialog component and intend to use it as an app-wide sidebar, you can try using Portal. When rendered inside the portal, it won't be affected by the parent container and the Portal parent container will have the attribute inert.

Using Next.js application: "

   const [root, setRoot] = useState<HTMLElement | null>(null);
   useEffect(() => {
      setRoot(document.getElementById('sidebar-root'));
   }, []);

   if (!root) return null;

// the SideNavigation is the dialog component to be rendered not in the parent container
   return ReactDOM.createPortal(
      <SideNavigation sidebarOpen={sidebarOpen} setSidebarOpen={setSidebarOpen}>
         {/* Modal content */}
      </SideNavigation>,
      root
   );
};

it fixes the problem if you add timeout inside useEffect , so it has tiime to first set the attributes and then remove them manually

[agustinglez]

@RobinMalfait Remove this ""feature"", or at least, make it optional. It causes more problems than it solves.

[samesfahani-tuplehealth]

FWIW, radix-ui allows an opt out via their modal property:

I've since migrated to use Radix with that flag set to false. I don't see a reason to not expose a similar flag here.

[haagOS]

the sidebar is meant to be an app-wide sidebar that is meant to persist with or without a dialog open

I had a similar use case and did a small POC using react portal: https://codesandbox.io/p/sandbox/3cddx5
The key here is that the sidebar element is on the same level as the react root element.
In the example you can open the dialog and still click the sidebars button (writes a log into the console).

[thiagoalvesfoz]

This decision to keep inert=true is terrible; it forces me to create ugly workarounds with multiple portals just to keep the snackbar working.

[sb8244]

I was pretty surprised by this today while playing around with a headlessui upgrade.

If you want a sidebar dialog (like TailwindUI examples), but allowing the app to still be interactable underneath it, then I don't think it's possible with anything that headlessui provides.

Am I wrong here and just missing something?