Is it worth making OverlayContext available in public API?

[nathanpower]

If OverlayContext was available, it would (I think?) offer consumers an escape hatch for focus trap issues in certain situations.

For example, we have a Modal component based on the Modal and ModalOverlay from react-aria-components. If I had access to the OverlayContext, I could allow focusing on the Storybook search input when the component rendered in an open state in Storybook (which we need for snapshot testing).

The data-react-aria-top-layer approach does not seem to work when the FocusScope is inside an iframe, which is how Storybook renders components.

[snowystinger]

We have some ongoing work on this which we're hoping to pick up again in the new year. I'm attaching some related discussions I found with a quick search, feel free to look for others and chime in on any that are specific to you.
Related issues:
#8952
#5126 (comment)

Out of curiosity, what, in OverlayContext, are you hoping would enable this?

What is blocking you in snapshot testing? Can you close the modal before moving to the next step?

[nathanpower]

Hey, thank you for quick reply 🙇

Out of curiosity, what, in OverlayContext, are you hoping would enable this?

Reading the source code, OverlayContext exposes a setContain that I figured I could use conditionally when running in Storybook.

Of course, it would be much easier if ModalOverlay just exposed a contain prop - but I figured you would be unlikely to want to do that, as it kind of encourages inaccessible focus behaviour.

What is blocking you in snapshot testing? Can you close the modal before moving to the next step?

Sorry, should have been clearer: Snapshot testing works fine. Its just that we want the same Storybook story to be used for snapshot testing, documentation and general dev.

You can see the issue here (try to use the main Storybook search box)

We also use Supernova to embed Storybook inside documentation, and when you are in edit mode in Supernova, the modal rendering inside an iframe (Supernova uses a frame too, so we have nested frames here) makes it impossible to use any of the input fields in the editor.

To be clear, I opened this in the hope of a quick workaround, I was aware of the discussions you linked. Personally I think that the focus scope should not extend beyond the iframe boundary by default (maybe I'm just missing cases where one would want this), or at least allow optionally sandboxing it to a frame, but it seems like it might take a while to get consensus on that.

Left my 2c on the existing Storybook issue too, it is quite closely related, if a bit broader.

[snowystinger]

You can see the issue here (try to use the main Storybook search box)

A workaround for this one is to make the modal closable. I noticed I can close it with the Esc key, but hooking up the buttons to also close would probably be a good thing.

Unfortunately for the rest though, I don't have a quick workaround for you. It's a systemic change that's needed. I think we'd be reluctant to expose setContain on the context for the same reasons we don't want to expose the contain prop.

[nathanpower]

I think we'd be reluctant to expose setContain on the context for the same reasons we don't want to expose the contain prop.

Fair enough, I can see why you would be.

It's a systemic change that's needed.

Ok, will follow the various threads in the new year, I appreciate it is a extremely tricky set of behaviours to define in way that pleases everyone.