dtourolle
f46d7bf676
Publish Documentation / Build & publish docs to gitea-pages (push) Canceled after 0s
🏗️ Build and Test JellyTau / Run Tests (push) Failing after 4m55s
🏗️ Build and Test JellyTau / Android Compile Check (push) Skipped
Traceability Validation / Check Requirement Traces (push) Successful in 20s
DR-161 flipped experimentalNativeVideo on by default so picture-in-picture could shrink a real video surface. On a device that shipped sound with a blank screen. The decode path was never at fault. Logcat shows ExoPlayer running and feeding a live SurfaceView with an active BufferQueue. The compositing was: the SurfaceView sits behind the WebView, and the step that clears the opaque layers above it never took effect — `WebView transparent = false` is logged, `= true` never appears. The video was rendering correctly the whole time, behind an opaque page. This is precisely the defect the flag existed to contain; VideoPlayer.scrubRegression.test.ts had already recorded that "the native SurfaceView has never been visible through the webview". Enabling it by default shipped a verified decode path on top of an unverified display path. Reverting costs nothing that matters: PiP does not depend on it — DR-160 drives PiP from the WebView <video> — and working video outranks PiP showing a native surface. The flag stays in Settings, now described as incomplete rather than as a performance win, so anyone helping test it still can. Fixing the compositing is the prerequisite for trying this default again (DR-172).
121 lines
4.0 KiB
TypeScript
121 lines
4.0 KiB
TypeScript
/**
|
|
* Picture-in-picture support, Android only.
|
|
*
|
|
* TRACES: UR-041 | IR-026 | DR-053
|
|
*
|
|
* Video on Android renders into a native ExoPlayer SurfaceView behind the
|
|
* WebView, so PiP is driven by the Activity (which shrinks into a floating
|
|
* window) rather than the HTML5 `requestPictureInPicture()` API. The bridge is
|
|
* the `AndroidPictureInPicture` @JavascriptInterface installed by MainActivity.
|
|
*
|
|
* On every other platform this module reports unsupported. Notably WebKitGTK
|
|
* (the Linux webview) does not implement the Picture-in-Picture Web API at all,
|
|
* so there is no HTML5 fallback to reach for.
|
|
*/
|
|
|
|
interface AndroidPictureInPictureBridge {
|
|
enterPip(): void;
|
|
isSupported(): boolean;
|
|
canEnterPip(): boolean;
|
|
setAutoEnterEnabled(enabled: boolean): void;
|
|
setHtml5VideoState(active: boolean, width: number, height: number, playing: boolean): void;
|
|
}
|
|
|
|
declare global {
|
|
interface Window {
|
|
AndroidPictureInPicture?: AndroidPictureInPictureBridge;
|
|
}
|
|
}
|
|
|
|
function bridge(): AndroidPictureInPictureBridge | undefined {
|
|
if (typeof window === "undefined") return undefined;
|
|
return window.AndroidPictureInPicture;
|
|
}
|
|
|
|
/**
|
|
* Whether the device can do PiP at all - used to decide if the button should
|
|
* be rendered. False on desktop, and on Android devices where the user has
|
|
* disabled the feature.
|
|
*/
|
|
export function isPipSupported(): boolean {
|
|
try {
|
|
return bridge()?.isSupported() ?? false;
|
|
} catch (err) {
|
|
console.warn("[PiP] isSupported check failed:", err);
|
|
return false;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Whether entering PiP would succeed right now: a native video must be playing
|
|
* locally. False during audio playback and while casting to a remote session.
|
|
*/
|
|
export function canEnterPip(): boolean {
|
|
try {
|
|
return bridge()?.canEnterPip() ?? false;
|
|
} catch (err) {
|
|
console.warn("[PiP] canEnterPip check failed:", err);
|
|
return false;
|
|
}
|
|
}
|
|
|
|
/** Enter picture-in-picture. No-op where unsupported. */
|
|
export function enterPip(): void {
|
|
try {
|
|
bridge()?.enterPip();
|
|
} catch (err) {
|
|
console.error("[PiP] Failed to enter picture-in-picture:", err);
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Enable/disable auto-entering PiP when the user backgrounds the app.
|
|
*
|
|
* This is a coarse frontend override; the authoritative gate is the native
|
|
* `canEnterPip` guard, which already refuses PiP unless a local video surface
|
|
* is actively rendering (so audio playback, menu/library browsing, and
|
|
* remote/cast sessions never enter PiP regardless of this flag). The only
|
|
* caller today is the background-audio toggle, which disarms auto-PiP so the
|
|
* two background behaviours stay mutually exclusive.
|
|
*/
|
|
export function setAutoEnterEnabled(enabled: boolean): void {
|
|
try {
|
|
bridge()?.setAutoEnterEnabled(enabled);
|
|
} catch (err) {
|
|
console.warn("[PiP] Failed to set auto-enter:", err);
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Tell native that a WebView `<video>` is (or is no longer) the playback surface.
|
|
*
|
|
* This is what makes PiP work on the HTML5 path. The native side only ever knew
|
|
* about the ExoPlayer surface, and that path is behind `experimentalNativeVideo`,
|
|
* which defaulted to off when this was written — so `canEnterPip` was always
|
|
* false and pressing the button did nothing. Reporting the element's state gives
|
|
* native a surface it can legitimately shrink into, plus the intrinsic size it
|
|
* needs for the PiP window's aspect ratio and the play state for its play/pause
|
|
* action.
|
|
*
|
|
* The flag is back to defaulting **off** (DR-172, after native video shipped as
|
|
* audio with no picture), so this is once again the path Android normally takes —
|
|
* which is why PiP does not depend on that flag being on.
|
|
*
|
|
* Pass `active: false` when the element goes away, or PiP would be offered over a
|
|
* video that is no longer there.
|
|
*
|
|
* TRACES: UR-041 | DR-160
|
|
*/
|
|
export function setHtml5VideoState(
|
|
active: boolean,
|
|
width: number,
|
|
height: number,
|
|
playing: boolean
|
|
): void {
|
|
try {
|
|
bridge()?.setHtml5VideoState(active, Math.round(width), Math.round(height), playing);
|
|
} catch (err) {
|
|
console.warn("[PiP] Failed to report HTML5 video state:", err);
|
|
}
|
|
}
|