summaryrefslogtreecommitdiff
path: root/app/src/test/resources
diff options
context:
space:
mode:
authorPeter Stone <thepeterstone@gmail.com>2026-10-21 23:47:13 +0000
committerPeter Stone <thepeterstone@gmail.com>2026-10-21 23:47:13 +0000
commit4dd59a40c8a8fed3008082da45e29c1c188b7fe8 (patch)
tree6beb517fe10c731013bbdd42c4c88c81cc4fe8a7 /app/src/test/resources
parent9210bf463a8818595f7ca42486a787d4f1941d55 (diff)
Play the YouTube embed with a referrer instead of in an iframe
Peter, on the previous build: "the inline player now plays the audio but the video is a black screen." So Error 153 is gone and the stream is decoding -- what is left is a display problem. The iframe was not needed in the first place. A `Referer` header alone satisfies the embed, which means the player can be the WebView's own ordinary top-level document again. That drops two constructs the last build added: a `loadDataWithBaseURL` page, whose origin is synthetic, and a cross-origin subframe inside it. Both have a history of rendering video oddly in WebView, and the black screen appeared with them. Measured on an Android user agent -- no referrer: Error 153; `&origin=` in the query: Error 153; inside an iframe: plays; with a `Referer` header: plays. The referrer is a constant on a reserved `.invalid` domain rather than the article's URL, so YouTube learns which app asked and nothing about what is being read -- the same reason the nocookie domain is used. Confirmed in the app's own WebView: the embed loads with no error, 854x480, readyState 4, playing. NOT confirmed: that a picture now reaches the screen. This emulator cannot render video in a WebView at all -- it hard-crashed the AVD twice, including on a plain <video> in an ordinary non-dialog WebView -- so the one thing that matters here can only be checked on real hardware. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
Diffstat (limited to 'app/src/test/resources')
0 files changed, 0 insertions, 0 deletions