'use client'; /** * iOS app shell only: hand the player's fullscreen control to Apple's own video * player instead of the Fullscreen API. * * This is what media-chrome already does on iPhone Safari — `requestFullscreen` * does not exist on `Element.prototype` there, so its `enterFullscreen` falls * through to `media.webkitEnterFullscreen()` and the video is handed to the * system player. The Capacitor shell turns element fullscreen ON (WKWebView's * `isElementFullscreenEnabled`), so media-chrome takes the `requestFullscreen()` * branch instead — and WebKit then hands the web view back with its scroll * view's `contentInsetAdjustmentBehavior` reset from Capacitor's `.never` to * `.automatic` and its own `safeAreaInsets` stranded at the fullscreen * container's values. The app comes back from a video with a doubled top band * and dead space above the home indicator until a rotation, and the shell can * only paper over it afterwards (`MainViewController` KVOs `fullscreenState` to * restore the behavior). Never entering element fullscreen is the actual fix. * * The takeover is an event interception, not a monkey-patch: the fullscreen * button dispatches `mediaenterfullscreenrequest` (`composed`, `bubbles`) from * inside the player's shadow trees, so a CAPTURE listener on the `` * host sees it before the `` that would service it, and * `stopImmediatePropagation()` is enough to claim the request. Which element * media-chrome would have passed to `requestFullscreen` never enters into it. * * The player's own fullscreen STATE stays correct for free: the system player * fires `webkitbeginfullscreen` / `webkitendfullscreen` on the `