From 04408cceea17f3e32b6e88edf4da94b26385b026 Mon Sep 17 00:00:00 2001 From: Peter Stone Date: Fri, 23 Oct 2026 10:34:01 +0000 Subject: 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 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 Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B --- BACKLOG.md | 25 +++++++++++++++- .../java/org/terst/feedreader/ui/ReaderWebView.kt | 10 +++++++ .../java/org/terst/feedreader/ui/YouTubeLinks.kt | 35 ++++++++++++++++++++++ .../org/terst/feedreader/ui/YouTubeLinksTest.kt | 29 ++++++++++++++++++ 4 files changed, 98 insertions(+), 1 deletion(-) 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 +`` 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 `