[masnwilliams]

Summary

On iPhone the live view flashes black on most taps and key presses since #480, in Safari and in Chrome. Every iOS browser runs on WebKit, so they share the behavior below.

#480 reloads the video from its stream when it is playing but has decoded no frame since a check at least a second earlier, and runs that check on every touchend and key press. Frames are counted with getVideoPlaybackQuality().totalVideoFrames, which WebKit on iOS does not report for a MediaStream (it stays 0; WebKit bug 310007). So in iOS browsers every interaction more than a second after the previous one counted as a stall and reset srcObject, which blanks the video until the next frame arrives.

Changes

• VideoResume only detects stalls once the frame counter has reported a frame. A counter stuck at 0 says nothing about a stall, so iOS browsers keep the paused-video recovery from Keep the live view video playing on Android, and resume it when it stops #480 (play, muted fallback, "Tap to resume video") but no longer reload a playing stream. Browsers whose counter advances behave as before; Chromium on Linux, with and without iPhone emulation, counted MediaStream frames in testing.

Testing

• bun test tests: 251 pass. The new test (a counter that stays at 0 across checks a second apart is never reloaded) fails against the previous video-resume.ts.
• Playwright WebKit (Linux, iPhone 13 profile) against two production browsers serving the deployed live view client, one unmodified and one with only this change applied to its bundle. Linux WebKit crashes decoding the live view's VP8 track, so the track was swapped for a moving canvas track, and getVideoPlaybackQuality() was stubbed to report 0 frames as iOS WebKit does. Four taps 1.3s apart:
  • before: taps 2–4 each reset srcObject (emptied, readyState 0), leaving the video with no picture for 124–145ms; screenshots right after those taps are black;
  • after: no reloads, no blank frames;
  • with Linux WebKit's real frame counter (which, unlike iOS WebKit, counts MediaStream frames), neither version reloads.
• Tested on a physical iPhone, in Safari and in Chrome (both showed the flash before), against a production browser serving the deployed live view client with this change and Send iOS AutoFill text to the live view's remote field once #489 hot-patched in. Taps and typing no longer flash the video black in either browser.

---

Note

Low Risk
Targeted change to client-side stall heuristics for live video; Chrome stall recovery is preserved and Safari avoids erroneous reloads.

Overview
Fixes live view flashing black on most taps/key presses in Safari by tightening when stall recovery reloads the stream.

VideoResume used getVideoPlaybackQuality().totalVideoFrames to detect a playing video that stopped decoding; Safari keeps that at 0 for MediaStream, so every interaction after ~1s was treated as a stall and srcObject was reset. The change adds a counting gate: stall reload only runs after the frame counter has reported at least one frame (progress > 0). Browsers that never advance the counter skip reload but still get paused/blocked playback handling from #480; Chrome behavior is unchanged.

Adds a unit test that a video with frames stuck at 0 is never reloaded across repeated stall-interval checks.

^{Reviewed by Cursor Bugbot for commit fa7a153. Bugbot is set up for automated code reviews on this repo. Configure here.}

[masnwilliams]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit fa7a153. Configure here.}