Fullscreen Needs a Container, Not Just a Player

repovideoweb-componentsreactmuxmedia-uifrontendvideo-pipeline

custom fullscreen containers map directly to richer joelclaw video embeds where player-adjacent UI should travel fullscreen with the media

Mux finally added custom fullscreen container support to mux-player. The PR resolves an issue Joel filed in 2023: apps using MuxPlayer were stuck fullscreening the default player element, even when the actual user experience needed surrounding UI to come along for the ride.

The clever part is small: pass a fullscreen-element attribute, or a fullscreenElement React prop, and Mux Player looks up that DOM element by ID. It only applies the container when that element contains a mux-player, which keeps the API from turning into a footgun.

This matters because video rarely lives alone. A polished course player, clip review surface, transcript UI, or joelclaw video note can need controls, context, captions, overlays, or navigation to stay attached in fullscreen. Fullscreen as a container choice is a better primitive than fullscreen as a hardcoded player behavior.

The trail is also useful: Media Chrome added configurable fullscreen targets in PR #415, then Mux Elements caught up later. That’s the kind of upstream gap worth remembering when building on polished primitives: the lower layer may already know how to do the right thing, while the wrapper is still catching up.

Key Ideas

  • Mux Player now supports a custom fullscreen container via the fullscreen-element attribute.
  • mux-player-react exposes the same capability as a fullscreenElement prop for React apps.
  • The implementation checks that the chosen DOM element contains a mux-player before assigning it to the media controller’s fullscreen target.
  • Joel’s original feature request framed the problem as needing a more holistic fullscreen experience for complex app layouts.
  • Media Chrome already had the lower-level configurable fullscreen element support from PR #415.