Give YouTube's player a height, so the picture has somewhere to go

Peter, three builds running: audio plays, YouTube's title, controls and
scrubber thumbnails all draw, and where the picture belongs there is a
blank rectangle.

None of my guesses were right. It is not the embed, not the window, and
not the surface. It is layout. YouTube's player sizes itself with
`body { position: absolute; height: 100% }`, and in this WebView
percentage heights resolve against a containing block of zero height.
Measured in the running app: window.innerHeight correctly reports 214,
while 100vh and every percentage height resolve to 0. The body
collapsed, the player chain under it collapsed, and the video element
was laid out 380x0.

That explains the whole symptom, including the part I kept failing to
account for. The page, the chrome and the stream were all healthy --
the picture simply had nowhere to go, and what showed through the
zero-height player was YouTube's own white <html> background.

So the fix pins the player chain to the pixel height the page does
know and dispatches a resize so YouTube's own code re-measures.
Verified on a device, with the shipped code and nothing injected by
hand: the video element goes 380x0 -> 380x214 and the video plays.

Two things ruled out along the way, recorded so they are not retried:
hardware-accelerating the dialog's window changed nothing, and nor did
moving the player out of a dialog into an in-window overlay. An A/B
against BrowserScreen looked decisive for the window and was not --
that WebView differs in layout too, and layout was the real variable.

This treats the symptom. Why the viewport has no height is below this
app, in WebView.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B

1 files changed, 24 insertions, 1 deletions

diff --git a/BACKLOG.md b/BACKLOG.md
index 5bc7ea0..75d91d3 100644
--- a/BACKLOG.md
+++ b/BACKLOG.md
@@ -64,7 +64,30 @@ video in a cross-origin subframe of it -- and Peter then reported audio playing
 over a black screen. Both of those are WebView constructs with a history of
 rendering video oddly and neither was needed, so the referrer replaced them.
 
-**Not verified here: video actually appearing.** The emulator cannot render
+**Root-caused and fixed 2026-10-23, after three wrong guesses.** The symptom
+was audio and controls with a blank rectangle where the picture should be. The
+cause is not the window, the surface, or the embed: YouTube's player lays
+itself out with `body { position: absolute; height: 100% }`, and in this
+WebView percentage heights resolve against a zero-height containing block.
+Measured in the running app: `window.innerHeight` correctly reports 214 while
+`100vh` and every percentage height resolve to 0, so the body collapsed and
+the video element was laid out 380x0. The white Peter saw was YouTube's own
+`<html>` background showing through a player with no height.
+
+`YOUTUBE_FIT_PLAYER_JS` runs on page load and pins the player chain to the
+pixel height the page does know, then dispatches a resize so YouTube
+re-measures. Verified on a device: video element 380x0 -> 380x214, picture
+appears. It treats the symptom; why the viewport is zero-height sits below
+this app in WebView itself.
+
+Two earlier guesses are recorded because they were wrong and should not be
+retried: setting FLAG_HARDWARE_ACCELERATED on the dialog's window changed
+nothing, and neither did moving the player out of a dialog into an in-window
+overlay. An A/B against BrowserScreen looked decisive for the window
+hypothesis and was not -- BrowserScreen's WebView also differs in layout, and
+layout was the real variable.
+
+**Superseded note, kept for the record:** The emulator cannot render
 video in a WebView at all -- it hard-crashes the whole AVD, twice, including on
 a plain `<video>` element in an ordinary non-dialog WebView. Everything short of
 display is confirmed on-device (no error, 854x480, readyState 4, playing), but