- Shipped
- August 20, 2026 at 3:33 PM UTC
- Author
- Kamo
- Commit
- 25d0059
Follow-up to the still. Testing tap-to-play against the deployed site turned up a failure mode the muted fallback did not cover. A refused `play()` rejects, and that was already handled. The quiet failure is worse: the browser RESOLVES the promise, reports `paused: false` and a healthy readyState, keeps buffering past twenty seconds — and never advances the clock, because it cannot render audio. The reader taps play and looks at a frozen frame with nothing in the console. Reproduced exactly that way in headless Chrome, which has no audio output device. So playback progress is checked rather than assumed, and two details of that check both had to be wrong before it worked: · The watchdog cannot hang off `.then()`. That was the first attempt and it never fired, for the obvious reason once seen: in the stalled case the promise settles neither way, so a handler attached to it is precisely the thing that cannot run. It is armed on a clock before play() instead. · It cannot compare against zero. A stalled element still decodes its first frame, so `currentTime` reads 0.021 rather than 0 — measured — and a naive `> startedAt` test calls that playback and lets the freeze through. The threshold is a quarter of a second: well clear of one frame, well under anything healthy. Worst case is now muted playback instead of a still frame that never moves. Verified: unmuted attempt stalls at one frame, the watchdog mutes at ~1.5s, and currentTime then advances 2.5 -> 7.5s. Console and Issues clean, all guards pass. NOTE FOR REVIEW: this environment has no audio device, so unmuted playback is the one thing here I cannot confirm — worth a press of play on a real machine to hear that it starts with sound rather than silently taking the fallback.