[miguel-heygen]

What

A film with a video the browser never starts loading now moves on after the usual 5 s wait, instead of freezing. The runtime skips that video and names it in a warning: skipping "…/clip.mp4": the browser never started loading it; the rest plays.

Why

Safari sometimes leaves a video at networkState LOADING and readyState HAVE_NOTHING without ever sending its request. #7347 traced this in the Safari perf runs: the server receives no request, and the page has no resource-timing entry. The runtime holds playback while a due video has no data. The skip from #7355 covers a video that stopped after its header (HAVE_METADATA and NETWORK_IDLE), but not this state, so a viewer's film held at that frame indefinitely. A one-time load() does not recover it (#7347).

Related work

• Extends fix(core): skip a video the browser can't decode instead of freezing the film #7355's skip in isUnplayable, with the same 5 s wait from the first play request and the same one-time warning.
• Follows test(player): a Safari perf run that fails says which wait timed out and why #7347, which named the same state in the Safari perf bench.

How

• media.ts: stallSinceFirstAsk returns why a video is stalled 5 s after it was first asked to play. It is either "after its header" (fix(core): skip a video the browser can't decode instead of freezing the film #7355's case) or "never started": HAVE_NOTHING and NETWORK_LOADING with no progress event since it was first asked to play.
• The progress condition keeps a slow fetch waiting. Bytes are arriving there, so the browser did start it.
• isUnplayable uses that reason in its warning. Playback, the playhead's media hold and the audio clock already skip anything isUnplayable reports, so the film moves on.
• An emptied event (a new source) clears both the wait and the bytes mark, as it already cleared the wait.
• Preview and player playback only. Renders seek frame by frame and do not use this path.

Test plan

• Unit tests added in media.test.ts: a clip at HAVE_NOTHING and NETWORK_LOADING is kept at 4999 ms, then skipped and named at 5000 ms. The same clip with a progress event is still kept at 60 s.
• Film-level test added in init.test.ts: a muted video in that state, played for 7 s of frames, moves the playhead past 1 s and logs the warning.
• Fails without the fix: with the "never started" case removed, the film test's playhead stays at 0.017 s after 7 s and the unit skip test fails. Ignoring progress fails the slow-fetch test.
• media.test.ts (190 tests) and the new film test pass 3 runs in a row. The whole runtime suite passes (2864 tests). Core typecheck, test:hyperframe-runtime-ci, oxlint, oxfmt and the comment checks are clean.

Size

One state added to the existing skip check, plus three tests.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 103 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (1)

• seqplainkeys-none-pct-r0-nested-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo false, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true

[heygengenesis]

Approve at 222fd344. No blockers.

Verified

• Fails without the fix: with media.ts from origin/main, two tests fail: init.test.ts › "a video the browser never starts loading › moves the film on past it after the wait and names it", and media.test.ts › "skips and names a clip the browser never started loading 5 s after it was asked to play". Both pass at this head, and so does the slow-fetch (progress) test.
• All of media.test.ts passes (190 tests).
• A skipped clip can still recover. isUnplayable is checked again on every tick, so a late first byte fires progress and the clip plays again. A NotAllowedError refusal still clears the wait, and emptied clears both marks.
• The runtime does not use MSE or HLS, so a blob: source that never fires progress cannot be wrongly skipped.

Non-blocking note: with a time to first byte over 5 s, the film now moves on without that video, and the video joins late. Before, the film held. This matches the tradeoff #7355 already made, but the Player Safari perf run on this head is still in progress, so it is worth reading before merge.