How to properly deal with portal containers and the fullscreen API?

[janvorwerk]

Hello gents,

My app is using the DOM fullscreen API for several cases.

Let's consider two of them:

1. Part of the screen needs a lot of screen space… and still has many interactions that will open portaled content (popover…)
2. A dialog (Modal for instance) is showing a Youtube iframe, in which the user wants to trigger full screen mode to better view the video

By default, case 1 does not work because as soon as the component goes fullscreen, the document.body seems no longer visible so that any portaled component isn't either.

What I thought was a very smart move was to use the PortalProvider… despite the fact that it was flagged "UNSAFE".

export function SkPortalProvider(props: { children: ReactNode }) {
  return <UNSAFE_PortalProvider getContainer={getDomRoot}>{props.children}</UNSAFE_PortalProvider>;
}

function getDomRoot(): HTMLElement | null {
  return document?.fullscreenElement instanceof HTMLElement ? document.fullscreenElement : document.body;
}

Clever, ugh? Actually not so much because then, case 2 won't work any longer : as soon as the video goes fullscreen, the portal is changed, so that the dialog containing the video node vanishes…

Then I tried to be more clever than ever 😁…

function getDomRoot(): HTMLElement | null {
    // If there are existing modals/dialogs in document.body, keep using document.body
    // to avoid moving them when fullscreen is triggered. This prevents modals from
    // disappearing when fullscreen is activated.
    const hasExistingModals = document.body?.querySelector('[role="dialog"], [role="alertdialog"]') != null;
    
    if (hasExistingModals) {
      return document.body;
    }
    
    // Otherwise, use fullscreen element if available (for popovers within fullscreen),
    // or document.body as fallback
    return document?.fullscreenElement instanceof HTMLElement ? document.fullscreenElement : document.body;
}

… but then case 1 no longer works properly…

Hence my questions: did you guys consider using/supporting fullscreen? How did you do?

Many thanks in advance 🙏

[snowystinger]

Thanks for the discussion. We created the PortalProvider partially because someone needed to make use of fullscreen. It doesn't look like the group that needed fullscreen support contributed any tests however and we don't make use of it ourselves at the moment, so there may be some gaps we're unaware of. Would you be willing to put together a small test app in codesandbox or stackblitz or even in our storybook? That's probably the easiest way to diagnose what's going on or if it's just differing expectations.

At the very least, I think you're on the right track

[janvorwerk]

Thanks for the reply. Here is a test case that demonstrate the issue(s):

https://github.com/janvorwerk/react-aria-fullscreen (you even have the live demo on Vercel: link on the repo).

With the current code state ENABLE_PORTAL_PROVIDER = true, you can see that the dialog opens properly while in fullscreen… however, the video within the dialog no longer goes fullscreen.

The video directly in the <main> is there merely to show that this one still goes fullscreen, this is really due to the dialog & portal.

If you switch the flag to false, you get the other issue : once <main> is fullscreen, the dialog no longer opens.

Let me know if it's not clear.

Best

[janvorwerk]

FWIW, I have implemented a hacky workaround for my very specific use-case.

I add a data-fullscreen="true" attribute to my fullscreen-able components… the Youtube videos do not have this so it works as they go fullscreen but do not open react-aria dialog obviously. As you can see, it's a hack… but il allows me to avoid nasty bugs in my app while waiting for a fully working solution, which - I understand - will likely take some time.

function getDomRoot(): HTMLElement | null {
  if (
    document.fullscreenElement instanceof HTMLElement &&
    document.fullscreenElement.dataset["fullscreen"] === "true"
  ) {
    return document.fullscreenElement;
  }
  return document.body;
}

[snowystinger]

Ah, I see, so it's trying to switch from the fullscreen dialog to the video as being the portal provider root?

I'm not sure what we'd do on our end yet, and I'm about to leave for vacation, so won't be able to think about it deeply for a while. What would you expect for a solution?

Thank you very much for putting together the app, I think it'll be very helpful in creating some tests.

[janvorwerk]

You're welcome for the test case! That's the least I can do: you guys have put together this awesome library… and are always answering my genuine questions.

What would you expect for a solution?

Well… if the question is "do you imagine a working solution?" => the answer is unfortunately not really at this point. I was thinking that there might be a way to capture fullscreenchange events and keep our own portal in state rather than using document.fullscreenElement but I did not think it through yet: I was waiting for your feedback. If I have an idea, I'll post here.

Anyway, enjoy your vacation 🚀, and as explained, I see no hurry for my case, it's just that my workaround does not handle all possible cases.

[janvorwerk]

Hi @snowystinger !
Any update on this full-screen issue?
Now that we've got a test case etc… shouldn't I file an issue so that it gets tracked?

[snowystinger]

I've converted it to an issue, #10506
Apologies, I've not had time to think about it :(

It would be interesting to see if an AI can find any prior art around this issue. Maybe that would be a good starting point for figuring out how we'd like to solve it.