Dialog Focus Trapping With Portals

[elson-currentcorp]

Assume I have a Select component inside a Dialog component, and both are rendered using portals.

What is the best way to handle trapping focus within the modal while still being able to loop through the Select options using arrow keys when the dropdown is open?

Seems like if the dropdown is rendered using a portal while inside a Dialog, the navigation accessibility features are disabled since focus is trapped within the Dialog.

[segunadebayo]

We'll update the docs shortly. I recommend avoiding using a portal within the modal dialog because it traps focus.

Removing the portal should make it work as expected.

[baptisteArno]

Honestly not a viable solution because it most likely won't look good...

With Portal:

Without Portal

The only workaround I see for now is setting closeOnInteractOutside to false. But not the best UX 😢

[baptisteArno]

This seems to do the job fine alongside closeOnInteractOutside={false}:

<Dialog.Positioner onClick={() => onClose()} className="pointer-events-auto">

<Dialog.Content onClick={(e) => e.stopPropagation()}>

[segunadebayo]

Could you try these alternatives?
#3544 (comment)

[maritaria]

I think this problem deserves a more dedicated solution, where these portals can be linked together (preferably automatically) so that the code can treat focus not by DOM hierarchy but also take portal hierarchy into account.

[maritaria]

Proposing to not have <Portal> available within <Dialog> reveals a limitation due to coupling. The current focus-trapping solution couples strongly to the DOM hierarchy, something that ark should attempt to offer a workaround for. The coupling is between the idea of what "outside" means and the DOM hierarchy. The initial solution works 99% of the time, but breaks when vnode/JSX hierarchy no longer ties to DOM hierarchy, which is exactly the function of <Portal>.

I feel it is justified to demand a solution here because <Portal> is offered by ark as well, ark has a built-in system for decoupling the JSX hierarchy from the DOM and so this is in-scope for focus handling as well.

As soon as you start a <Dialog> you should have context that anything inside here belongs to its DOM descendants, even if those DOM descendants are portalled away. Perhaps a way to do this is to give <Portal>-ed elements a data-focus-parent attribute, and allow focus to jump around instead of only bubbling up. Then when an element is clicked you can travel the DOM nodes upwards and if you hit one with a data-focus-parent then instead of following that element's parent you follow it by this element of data instead.

[maritaria]

Seems this may even be already supported in zag's dismissable layers, as @zagjs/dismissable mentions you can nest layers.

https://github.com/chakra-ui/zag/blob/main/packages/utilities/dismissable/README.md

[segunadebayo]

Indeed. This is already supported in Zag.js @maritaria

You can safely use portals as long as you lazy-mount them.