summaryrefslogtreecommitdiff
path: root/app/src/test/java/org/terst/feedreader/readability/PreferredSourceBadgeTest.kt
diff options
context:
space:
mode:
authorPeter Stone <thepeterstone@gmail.com>2026-10-23 10:34:01 +0000
committerPeter Stone <thepeterstone@gmail.com>2026-10-23 10:34:01 +0000
commit04408cceea17f3e32b6e88edf4da94b26385b026 (patch)
tree53de57968c54e09501319a7abe3415073abf504e /app/src/test/java/org/terst/feedreader/readability/PreferredSourceBadgeTest.kt
parentd4538340fdbe7016a7b3a2eb040c7b133df19efe (diff)
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
Diffstat (limited to 'app/src/test/java/org/terst/feedreader/readability/PreferredSourceBadgeTest.kt')
0 files changed, 0 insertions, 0 deletions